devfs
[Top] [All Lists]

Re: ttyS1, S2, etc...

To: tytso@xxxxxxx, jurgen@xxxxxxxx
Subject: Re: ttyS1, S2, etc...
From: "Khimenko Victor" <devfs@xxxxxxxxxxxxxxxxx>
Date: Sat, 18 Mar 2000 14:18:56 +0300 (MSK)
Cc: rgooch@xxxxxxxxxxxxx, devfs@xxxxxxxxxxx
Organization: MCCME
References: <200003170543.AAA02886@xxxxxxxxxxxxxxxxxxxx> <200003161751.JAA24104@xxxxxxxxxxxxx>
Sender: owner-devfs@xxxxxxxxxxx
17-Mar-00 00:43 you wrote:

All this setserial stuff is just a hack. Why you can not just use normal way:
command-line kernel parameters and/or module parameters like other devices
(like IDE or SCSI) are doing ? What's so special with serial ports anyway ?
It's onething to change settings of device via ioctl (number of stop-bits,
speed of port, etc) and it's other task to specify IRQ or IO port number.
For latter most other drivers are using module command-lines, not magic ioctls

>    Date: Thu, 16 Mar 2000 09:51:18 -0800
>    From: Jurgen Botz <jurgen@xxxxxxxx>

>    Richard Gooch wrote:
   >> In drivers/char/serial.c:register_serial() there are calls which
   >> create devfs entries. So the low-level serial driver should call
   >> register_serial() and everything should be fine. It certainly works
   >> for PCMCIA serial cards. Insert the card and the devfs entry magically
   >> appears.

>    The problem is that ISA multiport serial cards don't appear to be
>    detected by the kernel at all and register_serial never gets called.
>    To use the ports you set the IO base and IRQ with setserial which
>    sets them in the driver with ioctls on the device.  This bypasses
>    register_serial in the driver, too, so even if I create /dev/ttyS2
>    and then do the setserial thing, /dev/tts/2 still doesn't appear
>    (but /dev/ttyS2 then works fine).  Not that that would make a
>    difference for devfs, of course.

> Right.  There are actually two parts to this problem.  The first is that
> when setserial calls TIOCSSERIAL to change the uart from "none" to
> "non-none" and vice versa, tty_register_devfs() and
> tty_unregister_devfs() needs to be called.  I can fix this in the serial
> driver fairly easily, and this will take care of the problem which you
> reported.

> The second problem is how do you actually get setserial to set the port,
> irq, and uart settings using only devfs in the first place.  The issue
> here is that you can't autodetect ISA multiport serial cards, at least
> not those cards that don't have PNP support.  The port and irq settings
> either have to manually configured such as is the case for COM 1/2/3/4,
> or the user has to manually set them using the setserial command.

> But, in a devfs only world, the device file doesn't appear until the
> port is configured, but setserial needs the device file in order to
> configure the port.   There's no real way around this....

>    That may not be worth the trouble to provide automatic devfs
>    support for the diminishing number of non-PNP ISA multiport
>    boards out there.  Since I currently have to run an rc script
>    to configure the ports anyway, I might as well create the device
>    files there with mknod.

> Perhaps, but this isn't very satisfying; it's certainly very awkward for
> users, and for people who were accustomed to things Just Working (tm) in
> Linux 2.2, it's really, really, really ugly to tell them that they have
> to manually mknod the device in devfs.  However, short of telling them
> (a) don't use devfs, or (b) hacking setserial to automatically do the
> mknod if /dev/ttyS* is passed in and /dev/ttyS* doesn't exist.  Both
> aren't pretty solutions, though.

> What makes this worse is that I've been encouraging people to use rc
> scripts for configuring ISA multiport cards, since there are so many of
> them and using compiled in, hard-coded configuration parameters is
> evil.  The /devfs model doesn't seem to allow this terribly easily,
> unfortunately.

> I suppose we could shovel all of this dirt under the devfsd rug, and
> make devfsd responsible for parsing some new serial configuration file
> which then does the mknod and TIOCSERIAL ioctl.  But that's not that
> great of a solution either.

> I'll need to think about this one some more.   I'm not particularly
> happy with any of these solutions.  Richard, what do you think?


>                                               - Ted




<Prev in Thread] Current Thread [Next in Thread>