mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Adam J. Richter" <adam@yggdrasil.com>
To: linux-kernel@vger.kernel.org
Subject: Re: devfs + PCI serial card = no extra serial ports
Date: Sat, 8 Mar 2003 11:48:20 -0800	[thread overview]
Message-ID: <200303081948.LAA05459@adam.yggdrasil.com> (raw)

[Sorry if this is a duplicate.  I sent it about 12 hours ago, and it still
has not appeared on marc.theaimsgroup.com or www.uwsg.indiana.edu.-Adam]

On Fri, Mar 07, 2003, Theodore Ts'o wrote:
>On Fri, Mar 07, 2003 at 02:51:45PM -0800, Bryan Whitehead wrote:
>> It seems devfsd has an annoying "feature". I bought a PCI card to get a 
>> couple (2) more serial ports. The kernel doesn't seem to set up the 
>> serial ports at boot, so devfs never creates an entry. However, post 
>> boot, since there is no entries, I cannot configure the serial ports 
>> with setserial. So basically devfsd = no PCI based serial add on?
>
>Yep.  This I pointed this out as a flaw to devfs a long, long time
>(years!) ago, but Richard chose not to listen to me.  Personally, I
>solve this (and other) problems by simply refusing to use devfs.
>
>                                                - Ted

        Let me see if I understand the problem.  The sitution is
that you have "stem cell" devices which initially are not defined
to talk to a particular port, but which are then differentiated
by a user level program doing ioctls to set the associated IO
ports, interrupts and even UART types.  For example, exactly which
kernel device is associated with which hardware device is controlled
by user level software.

        There is nothing in devfs that prevents you from registering
devfs devices even if they are not yet bound to specific hardware
(you do not need a sysfs mapping, for example).  So, you should be
able to register /dev/tts/0..N at initialization, where N is the
maximum number of serial devices you want to support.

        Another approach, which I think provides a little more
information to users, makes for a more readable /dev tree and should
make some programs a few cycles faster would be to what my version of
/dev/loop does (not the one currently in Linus's tree, alas): start by
just creating /dev/tts/0, and then create /dev/tts/n+1 whenever
/dev/tts/n is assigned and /dev/tts/n+1 has not already been defined.
For /dev/loop, it was also useful to have the extra devices unregister
when the highest number device became undefined (if a device in the
middle were de-defined, it would not disappear until all higher
numbered devices were also de-defined).

        Is this the issue, or do I misunderstand?

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

             reply	other threads:[~2003-03-08 19:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-08 19:48 Adam J. Richter [this message]
2003-03-10 18:25 ` Bryan Whitehead
2003-03-14 15:23   ` David Woodhouse
  -- strict thread matches above, loose matches on Subject: below --
2003-03-15  0:54 Ed Vance
2003-03-15  0:02 Adam J. Richter
2003-03-14 20:28 Adam J. Richter
2003-03-14 20:43 ` Russell King
2003-03-14 19:49 Ed Vance
2003-03-14 20:07 ` Russell King
2003-03-14 19:06 Adam J. Richter
2003-03-10 18:37 Adam J. Richter
2003-03-10 17:12 Ed Vance
2003-03-08  1:30 Ed Vance
2003-03-07 23:57 Ed Vance
2003-03-08  0:59 ` Bryan Whitehead
2003-03-11  9:07 ` Theodore Ts'o
2003-03-07 23:40 Ed Vance
2003-03-08  0:15 ` Marek Michalkiewicz
2003-03-07 23:04 Ed Vance
2003-03-07 23:17 ` Bryan Whitehead
2003-03-07 22:51 Bryan Whitehead
2003-03-07 22:55 ` Bryan Whitehead
2003-03-07 23:28 ` Bryan Whitehead
2003-03-08  0:10   ` Marek Michalkiewicz
2003-03-07 23:38 ` Theodore Ts'o
2003-03-11 23:12 ` whitnl73

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200303081948.LAA05459@adam.yggdrasil.com \
    --to=adam@yggdrasil.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®