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?
03:05.0 Serial controller: NetMos Technology 222N-2 I/O Card (2S+1P)
(rev 01) (prog-if 02 [16550])
Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device 0002
Flags: medium devsel, IRQ 17
I/O ports at ecf8 [size=8]
I/O ports at ece8 [size=8]
I/O ports at ecd8 [size=8]
I/O ports at ecc8 [size=8]
I/O ports at ecb8 [size=8]
I/O ports at eca0 [size=16]
mknod ttyS2 c 4 66
mknod ttyS3 c 4 67
setserial ttyS2 port 0xecf8 UART 16550A irq 17 Baud_base 9600
setserial ttyS3 port 0xece8 UART 16550A irq 17 Baud_base 9600
I hoped after "setting up" the serial ports with setserial some magic
would happen and they would apear in /dev/tts... but I was wrong.
gets me working serial ports... but it's not in /dev... :O
Am I just screwed?
If so, what would be a good add on PCI based solution for more serial
ports that WORKS with devfsd? (I don't want to disable devfs as this
opens up a different set of problems)
Thanks for any replay!
--
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903
[email protected]
BTW, this is with 2.4.19 (kernel shipped with distro).... I'm willing to
test any patches / rebuild kernel to get this working.....
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?
>
> 03:05.0 Serial controller: NetMos Technology 222N-2 I/O Card (2S+1P)
> (rev 01) (prog-if 02 [16550])
> Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device
> 0002
> Flags: medium devsel, IRQ 17
> I/O ports at ecf8 [size=8]
> I/O ports at ece8 [size=8]
> I/O ports at ecd8 [size=8]
> I/O ports at ecc8 [size=8]
> I/O ports at ecb8 [size=8]
> I/O ports at eca0 [size=16]
>
>
> mknod ttyS2 c 4 66
> mknod ttyS3 c 4 67
> setserial ttyS2 port 0xecf8 UART 16550A irq 17 Baud_base 9600
> setserial ttyS3 port 0xece8 UART 16550A irq 17 Baud_base 9600
>
> I hoped after "setting up" the serial ports with setserial some magic
> would happen and they would apear in /dev/tts... but I was wrong.
>
> gets me working serial ports... but it's not in /dev... :O
>
> Am I just screwed?
>
> If so, what would be a good add on PCI based solution for more serial
> ports that WORKS with devfsd? (I don't want to disable devfs as this
> opens up a different set of problems)
>
> Thanks for any replay!
>
--
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903
[email protected]
Hi Bryan,
What serial driver initialization messages do you get from dmesg?
Is the "MANY_PORTS" flag present in the list of enabled options?
Which distribution and rev level are you using?
Ed
-----Original Message-----
From: Bryan Whitehead [mailto:[email protected]]
Sent: Friday, March 07, 2003 2:55 PM
To: [email protected]
Cc: [email protected]
Subject: Re: devfs + PCI serial card = no extra serial ports
BTW, this is with 2.4.19 (kernel shipped with distro).... I'm willing to
test any patches / rebuild kernel to get this working.....
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?
>
> 03:05.0 Serial controller: NetMos Technology 222N-2 I/O Card (2S+1P)
> (rev 01) (prog-if 02 [16550])
> Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device
> 0002
> Flags: medium devsel, IRQ 17
> I/O ports at ecf8 [size=8]
> I/O ports at ece8 [size=8]
> I/O ports at ecd8 [size=8]
> I/O ports at ecc8 [size=8]
> I/O ports at ecb8 [size=8]
> I/O ports at eca0 [size=16]
>
>
> mknod ttyS2 c 4 66
> mknod ttyS3 c 4 67
> setserial ttyS2 port 0xecf8 UART 16550A irq 17 Baud_base 9600
> setserial ttyS3 port 0xece8 UART 16550A irq 17 Baud_base 9600
>
> I hoped after "setting up" the serial ports with setserial some magic
> would happen and they would apear in /dev/tts... but I was wrong.
>
> gets me working serial ports... but it's not in /dev... :O
>
> Am I just screwed?
>
> If so, what would be a good add on PCI based solution for more serial
> ports that WORKS with devfsd? (I don't want to disable devfs as this
> opens up a different set of problems)
>
> Thanks for any replay!
>
--
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903
[email protected]
> What serial driver initialization messages do you get from dmesg?
> Is the "MANY_PORTS" flag present in the list of enabled options?
> Which distribution and rev level are you using?
My boot messages say this:
Serial driver version 5.05c (2001-07-08) with HUB-6 MANY_PORTS MULTIPORT
SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
It only sets up my built-into-motherboard serial ports. The add on card
gets ignored.
I would have thought with SERIAL_PCI enabled I would have no problem.
But it doesn't seem to be so.
doing the quick/dirty setserial stuff with my own mknod's work. but it's
a big "messy". I'd at least like to get this fixed so next kernel
version I don't need to do a quick hack todo something as simple as
getting a serial port working.
I can post my entire dmesg if needed allong with my complete /proc/pci.
I'm also willing to play with patches. (if this is already fixed in a
later kernel than 2.4.19 I'd be willing to give it a go).
> Ed
>
> -----Original Message-----
> From: Bryan Whitehead [mailto:[email protected]]
> Sent: Friday, March 07, 2003 2:55 PM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: devfs + PCI serial card = no extra serial ports
>
>
>
> BTW, this is with 2.4.19 (kernel shipped with distro).... I'm willing to
> test any patches / rebuild kernel to get this working.....
>
>
> 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?
>>
>>03:05.0 Serial controller: NetMos Technology 222N-2 I/O Card (2S+1P)
>>(rev 01) (prog-if 02 [16550])
>> Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device
>>0002
>> Flags: medium devsel, IRQ 17
>> I/O ports at ecf8 [size=8]
>> I/O ports at ece8 [size=8]
>> I/O ports at ecd8 [size=8]
>> I/O ports at ecc8 [size=8]
>> I/O ports at ecb8 [size=8]
>> I/O ports at eca0 [size=16]
>>
>>
>>mknod ttyS2 c 4 66
>>mknod ttyS3 c 4 67
>>setserial ttyS2 port 0xecf8 UART 16550A irq 17 Baud_base 9600
>>setserial ttyS3 port 0xece8 UART 16550A irq 17 Baud_base 9600
>>
>>I hoped after "setting up" the serial ports with setserial some magic
>>would happen and they would apear in /dev/tts... but I was wrong.
>>
>>gets me working serial ports... but it's not in /dev... :O
>>
>>Am I just screwed?
>>
>>If so, what would be a good add on PCI based solution for more serial
>>ports that WORKS with devfsd? (I don't want to disable devfs as this
>>opens up a different set of problems)
>>
>>Thanks for any replay!
>>
>
>
>
--
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903
[email protected]
I just found this:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0212.2/0845.html
Has this patch been accepted into the new kernel series? Or should I
just toss this card (the NetMos PCI I/O card)?
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?
>
> 03:05.0 Serial controller: NetMos Technology 222N-2 I/O Card (2S+1P)
> (rev 01) (prog-if 02 [16550])
> Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device
> 0002
> Flags: medium devsel, IRQ 17
> I/O ports at ecf8 [size=8]
> I/O ports at ece8 [size=8]
> I/O ports at ecd8 [size=8]
> I/O ports at ecc8 [size=8]
> I/O ports at ecb8 [size=8]
> I/O ports at eca0 [size=16]
>
>
> mknod ttyS2 c 4 66
> mknod ttyS3 c 4 67
> setserial ttyS2 port 0xecf8 UART 16550A irq 17 Baud_base 9600
> setserial ttyS3 port 0xece8 UART 16550A irq 17 Baud_base 9600
>
> I hoped after "setting up" the serial ports with setserial some magic
> would happen and they would apear in /dev/tts... but I was wrong.
>
> gets me working serial ports... but it's not in /dev... :O
>
> Am I just screwed?
>
> If so, what would be a good add on PCI based solution for more serial
> ports that WORKS with devfsd? (I don't want to disable devfs as this
> opens up a different set of problems)
>
> Thanks for any replay!
>
--
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903
[email protected]
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
Sure, go ahead and try the second patch that adds the Netmos cards to the
serial driver's device tables. It is for a somewhat newer rev, but you might
just get offsets with no failed hunks. It's worth a try.
The serial driver will only detect cards that are in the table. It does not
mean that there is anything wrong with the card.
Good luck,
Ed
-----Original Message-----
From: Bryan Whitehead [mailto:[email protected]]
Sent: Friday, March 07, 2003 3:28 PM
To: Bryan Whitehead
Cc: [email protected]; [email protected];
[email protected]
Subject: Re: devfs + PCI serial card = no extra serial ports
I just found this:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0212.2/0845.html
Has this patch been accepted into the new kernel series? Or should I
just toss this card (the NetMos PCI I/O card)?
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?
>
> 03:05.0 Serial controller: NetMos Technology 222N-2 I/O Card (2S+1P)
> (rev 01) (prog-if 02 [16550])
> Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device
> 0002
> Flags: medium devsel, IRQ 17
> I/O ports at ecf8 [size=8]
> I/O ports at ece8 [size=8]
> I/O ports at ecd8 [size=8]
> I/O ports at ecc8 [size=8]
> I/O ports at ecb8 [size=8]
> I/O ports at eca0 [size=16]
>
>
> mknod ttyS2 c 4 66
> mknod ttyS3 c 4 67
> setserial ttyS2 port 0xecf8 UART 16550A irq 17 Baud_base 9600
> setserial ttyS3 port 0xece8 UART 16550A irq 17 Baud_base 9600
>
> I hoped after "setting up" the serial ports with setserial some magic
> would happen and they would apear in /dev/tts... but I was wrong.
>
> gets me working serial ports... but it's not in /dev... :O
>
> Am I just screwed?
>
> If so, what would be a good add on PCI based solution for more serial
> ports that WORKS with devfsd? (I don't want to disable devfs as this
> opens up a different set of problems)
>
> Thanks for any replay!
>
--
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903
[email protected]
On Fri, Mar 07, 2003 at 3:39 PM, 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,
Will Bryan get the proper devfs entries if he patches serial.c to
recognize his card at kernel initialization, or is there more
weirdness expected?
Best regards,
Ed
----------------------------------------------------------------
Ed Vance edv (at) macrolink (dot) com
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------
On Fri, Mar 07, 2003 at 03:28:28PM -0800, Bryan Whitehead wrote:
> I just found this:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0212.2/0845.html
>
> Has this patch been accepted into the new kernel series? Or should I
> just toss this card (the NetMos PCI I/O card)?
No, and no. Try these patches (apply in this order, may need
some hand-patching to apply to the current 2.4.21-pre source):
http://www.amelek.gda.pl/linux-patches/2.4.20-pre9/00_parport_serial
http://www.amelek.gda.pl/linux-patches/2.4.20-pre9/01_netmos
Please test - I'd like to know if it works for you. It should -
I have 3 such cards in 2 servers, running patched 2.4.20 kernel
in production use for 3 months now (mainly serial ports used, but
2S1P cards were cheaper than 2S cards...). Attempts to submit
the changes have been ignored, so I gave up...
NetMos support was already in early 2.4.x kernels, later removed:
* parport_serial.c: Remove NetMos support, since it causes problems
for some people.
No idea what exactly these problems are, who "some people" are, why
NetMos support was not simply made a config option conditional on
CONFIG_EXPERIMENTAL, and why the link order bugfix (separate patch,
which only fixes an obvious bug) has been ignored too.
Perhaps you will have more luck than I did - test your card with the
patches for some time, if it works try to submit the patches again...
> >I hoped after "setting up" the serial ports with setserial some magic
> >would happen and they would apear in /dev/tts... but I was wrong.
I don't use devfs, so I never had this problem.
Hope this helps,
Marek
On Fri, Mar 07, 2003 at 03:40:31PM -0800, Ed Vance wrote:
> Sure, go ahead and try the second patch that adds the Netmos cards to the
> serial driver's device tables. It is for a somewhat newer rev, but you might
> just get offsets with no failed hunks. It's worth a try.
Note that the second patch depends on the first one (link order fix),
so please apply both patches in the order listed.
After 2.4.21 is released, I'll try to remember to update the patches.
Marek
Quick question: What PCI serial port add on card works with devfs in
kernel 2.4.19 out of the box? No pissing around?
While I'm messing around with the one I got (that doesn't work) I need
one that does... any suggestions??
Thanks to all for the help!!
Ed Vance wrote:
> On Fri, Mar 07, 2003 at 3:39 PM, 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,
>
> Will Bryan get the proper devfs entries if he patches serial.c to
> recognize his card at kernel initialization, or is there more
> weirdness expected?
>
> Best regards,
> Ed
>
> ----------------------------------------------------------------
> Ed Vance edv (at) macrolink (dot) com
> Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
> ----------------------------------------------------------------
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903
[email protected]
On Fri, Mar 07, 2003 at 4:59 PM, Bryan Whitehead wrote:
>
> Quick question: What PCI serial port add on card works with devfs in
> kernel 2.4.19 out of the box? No pissing around?
>
> While I'm messing around with the one I got (that doesn't
> work) I need
> one that does... any suggestions??
>
> Thanks to all for the help!!
>
[ snip ]
Bryan,
Anything in the /usr/src/linux*/drivers/char/serial.c driver's
serial_pci_tbl list (~line 4537) will be recognized. Also, a card _without_
a parallel port would solve the port ordering problem.
Cheers,
Ed
----------------------------------------------------------------
Ed Vance edv (at) macrolink (dot) com
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------
I had a similar problem, but the actual problem had nothing to do with the
devfs, the PCI serial card in question was not in the list of PCI devices.
(It was a one-off P.O.S.. from CompUSA.) Neither the serial ports nor
parallel port were recognized. The box claimed it was an 16PCI592 but the
chip maker had reved the chip ID.
The solution was to use scanpci to get the vendor and device numbers and
then add the numbers to pci_ids.h and then put an entry into the
serial_pci_tbl array in serial.c. It took a little investigative work to
find which PCI ids were for the card (I took it out, did a scanpci, put it
back in and did it again and looked at what changed. [I was very newbie at
the time 8-)])
Consider these two diffs, they added support for the card to the driver. I
had to guess at some of the values but fortunately there was a very similar
listing in serial.c already.
After that, the card appears in the device file system normally.
===== cut here =====
--- /tmp/pci_ids.h.orig 2003-03-07 17:59:07.000000000 -0800
+++ linux/include/linux/pci_ids.h 2002-07-29 01:51:19.000000000 -0700
@@ -1477,6 +1477,8 @@
#define PCI_DEVICE_ID_OXSEMI_16PCI952 0x950A
#define PCI_DEVICE_ID_OXSEMI_16PCI95N 0x9511
#define PCI_DEVICE_ID_OXSEMI_16PCI954PP 0x9513
+#define PCI_DEVICE_ID_OXSEMI_16PCI952DS 0x9521 // later rev or
something
+#define PCI_DEVICE_ID_OXSEMI_16PCI952PP 0x9513 // the Parallel Port
device
#define PCI_VENDOR_ID_AIRONET 0x14b9
#define PCI_DEVICE_ID_AIRONET_4800_1 0x0001
--- /tmp/serial.c.orig 2003-03-07 17:59:56.000000000 -0800
+++ linux/drivers/char/serial.c 2002-07-29 01:42:35.000000000 -0700
@@ -4658,6 +4658,9 @@
{ PCI_VENDOR_ID_OXSEMI, PCI_DEVICE_ID_OXSEMI_16PCI952,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_b0_2_115200 },
+ { PCI_VENDOR_ID_OXSEMI, PCI_DEVICE_ID_OXSEMI_16PCI952DS,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ pbn_b0_bt_2_115200 },
/* Digitan DS560-558, from [email protected] */
{ PCI_VENDOR_ID_ATT, PCI_DEVICE_ID_ATT_VENUS_MODEM,
===== cut here =====
(Note that this caused the devices to appear as /dev/(tts|cua)/4 and
/dev/(tts|cua)/5 even though I only have one other available serial port.
The first four (0..3) are reserved for the built in/reserved COM1 though
COM4 no matter what. This is expected.)
Alternately, if the card came with drivers, the manufacturer may have simply
chosen not to support the devfs filesystem. Nothing much you can do in that
case except yell at the manufacturer.
Rob.
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Bryan Whitehead
Sent: Friday, March 07, 2003 3:18 PM
To: Ed Vance
Cc: [email protected]; [email protected]
Subject: Re: devfs + PCI serial card = no extra serial ports
> What serial driver initialization messages do you get from dmesg?
> Is the "MANY_PORTS" flag present in the list of enabled options?
> Which distribution and rev level are you using?
My boot messages say this:
Serial driver version 5.05c (2001-07-08) with HUB-6 MANY_PORTS MULTIPORT
SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
It only sets up my built-into-motherboard serial ports. The add on card
gets ignored.
I would have thought with SERIAL_PCI enabled I would have no problem.
But it doesn't seem to be so.
doing the quick/dirty setserial stuff with my own mknod's work. but it's
a big "messy". I'd at least like to get this fixed so next kernel
version I don't need to do a quick hack todo something as simple as
getting a serial port working.
I can post my entire dmesg if needed allong with my complete /proc/pci.
I'm also willing to play with patches. (if this is already fixed in a
later kernel than 2.4.19 I'd be willing to give it a go).
> Ed
>
> -----Original Message-----
> From: Bryan Whitehead [mailto:[email protected]]
> Sent: Friday, March 07, 2003 2:55 PM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: devfs + PCI serial card = no extra serial ports
>
>
>
> BTW, this is with 2.4.19 (kernel shipped with distro).... I'm willing to
> test any patches / rebuild kernel to get this working.....
>
>
> 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?
>>
>>03:05.0 Serial controller: NetMos Technology 222N-2 I/O Card (2S+1P)
>>(rev 01) (prog-if 02 [16550])
>> Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device
>>0002
>> Flags: medium devsel, IRQ 17
>> I/O ports at ecf8 [size=8]
>> I/O ports at ece8 [size=8]
>> I/O ports at ecd8 [size=8]
>> I/O ports at ecc8 [size=8]
>> I/O ports at ecb8 [size=8]
>> I/O ports at eca0 [size=16]
>>
>>
>>mknod ttyS2 c 4 66
>>mknod ttyS3 c 4 67
>>setserial ttyS2 port 0xecf8 UART 16550A irq 17 Baud_base 9600
>>setserial ttyS3 port 0xece8 UART 16550A irq 17 Baud_base 9600
>>
>>I hoped after "setting up" the serial ports with setserial some magic
>>would happen and they would apear in /dev/tts... but I was wrong.
>>
>>gets me working serial ports... but it's not in /dev... :O
>>
>>Am I just screwed?
>>
>>If so, what would be a good add on PCI based solution for more serial
>>ports that WORKS with devfsd? (I don't want to disable devfs as this
>>opens up a different set of problems)
>>
>>Thanks for any replay!
>>
>
>
>
--
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903
[email protected]
[Sorry if this is a duplicate. I sent it about 12 hours ago, and it still
has not appeared on marc.theaimsgroup.com or http://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
[email protected] \ / 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."
On Sat, Mar 08, 2003 at 11:48 AM, Adam J. Richter wrote:
> [Sorry if this is a duplicate. I sent it about 12 hours ago,
> and it still
> has not appeared on marc.theaimsgroup.com or
> http://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
> [email protected] \ / 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."
Hi Adam,
The base issue on this one was that the card's PCI info was not in the
table of known serial cards (serial_pci_tbl) in serial.c, so the serial
driver did not detect and register it during system initialization.
Cheers,
Ed
----------------------------------------------------------------
Ed Vance edv (at) macrolink (dot) com
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------
[snip]
> 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.
are you saying there is a way to force devfs to make more entries in
/dev/tts/ without any hardware being attached to the entries? Then i can
use setserial? so on boot I'd have 4 entries in /dev/tts ?
Or are you saying I write a script to goto /dev/tts after boot and mknod
the ports that are missing?
> 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
> [email protected] \ / 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."
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Bryan Whitehead
SysAdmin - JPL - Interferometry Systems and Technology
Phone: 818 354 2903
[email protected]
Bryan Whitehead wrote:
>[snip]
>> 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.
>are you saying there is a way to force devfs to make more entries in
>/dev/tts/ without any hardware being attached to the entries? Then i can
>use setserial? so on boot I'd have 4 entries in /dev/tts ?
I don't know what you mean by "force." devfs_register does
not know (or "care") if there is a physical device associated with the
major/minor/ops that it is given.
>Or are you saying I write a script to goto /dev/tts after boot and mknod
>the ports that are missing?
User level programs can also do mknod() calls in devfs
directories, if that is what you are referring to, so you could
do "mknod /dev/tts/3 c 4 68", for example.
By the way, I notice that 2.5.64 with devfs already creates
/dev/tts/0 through /dev/tts/49.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / 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."
On Fri, Mar 07, 2003 at 03:57:56PM -0800, Ed Vance wrote:
>
> Will Bryan get the proper devfs entries if he patches serial.c to
> recognize his card at kernel initialization, or is there more
> weirdness expected?
The point is that with devfs, it requires a kernel patch. And if you
have an ISA card, where you can't do this kind of autoconfiguration,
and you're using devfs, you're *toast*. Without devfs, you just use
setserial to configure the necessary ports, and you're done.
(Granted, these days, the last point may not matter since ISA is
getting killed off pretty effectively by Microsoft refusing the
certify systems against recent Windows OS's if they contain ISA buses
--- one of the good things Microsoft has done for the computer
industry. :-)
- Ted
On Fri, 7 Mar 2003, 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?
>
> 03:05.0 Serial controller: NetMos Technology 222N-2 I/O Card (2S+1P)
> (rev 01) (prog-if 02 [16550])
> Subsystem: LSI Logic / Symbios Logic (formerly NCR): Unknown device 0002
> Flags: medium devsel, IRQ 17
> I/O ports at ecf8 [size=8]
> I/O ports at ece8 [size=8]
> I/O ports at ecd8 [size=8]
> I/O ports at ecc8 [size=8]
> I/O ports at ecb8 [size=8]
> I/O ports at eca0 [size=16]
>
>
> mknod ttyS2 c 4 66
> mknod ttyS3 c 4 67
> setserial ttyS2 port 0xecf8 UART 16550A irq 17 Baud_base 9600
> setserial ttyS3 port 0xece8 UART 16550A irq 17 Baud_base 9600
Why are you messing with baud_base? Don't, unless you really know what
you are doing. A normal 16550a with baud_base set to 9600 will run at
115200 when an app tries to run it at 9600. baud_base is just the
quotient the serial driver uses to calculate the divisor needed to
run the UART at a given speed.
>
> I hoped after "setting up" the serial ports with setserial some magic
> would happen and they would apear in /dev/tts... but I was wrong.
>
> gets me working serial ports... but it's not in /dev... :O
>
can you not make them? As in:
#mknod /dev/tts/5 c 4 69
...
> Am I just screwed?
>
> If so, what would be a good add on PCI based solution for more serial
> ports that WORKS with devfsd? (I don't want to disable devfs as this
> opens up a different set of problems)
>
> Thanks for any replay!
>
>
Lawson
--
---oops---
On Mon, 2003-03-10 at 18:25, Bryan Whitehead wrote:
> [snip]
> > 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.
>
> are you saying there is a way to force devfs to make more entries in
> /dev/tts/ without any hardware being attached to the entries? Then i can
> use setserial? so on boot I'd have 4 entries in /dev/tts ?
Don't do this. The whole concept of opening a device node for a device
which is _absent_, then doing magic ioctls on it to make the driver
probe for the hardware, is utterly bogus.
Fix it properly instead -- disallow opening of a /dev/ttySx node with
uart type unknown, and implement a proper way to tell the serial driver
'please look for a device _here_', via sysfs or something.
--
dwmw2
On 2003-03-14 at 15:23:50, David Woodhouse wrote:
>On Mon, 2003-03-10 at 18:25, Bryan Whitehead wrote:
>> [snip]
>> > 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.
>>
>> are you saying there is a way to force devfs to make more entries in
>> /dev/tts/ without any hardware being attached to the entries? Then i can
>> use setserial? so on boot I'd have 4 entries in /dev/tts ?
>Don't do this. The whole concept of opening a device node for a device
>which is _absent_, then doing magic ioctls on it to make the driver
>probe for the hardware, is utterly bogus.
>Fix it properly instead -- disallow opening of a /dev/ttySx node with
>uart type unknown, and implement a proper way to tell the serial driver
>'please look for a device _here_', via sysfs or something.
I don't know what you mean by "is utterly bogus." You need to
explain why you think this practice results in a larger kernel
footprint, lower throughput, longer latency, larger object or source
code size, or is worse by some other objective external metric when
compared to a specific alternative (another element you seem to have
omitted).
This is a frequent problem that I see in many public technical
discussions. Using intimidation words like "is utterly bogus" to
cover for not stating real technical reasons not only wastes peoples
time in reading an unnecessary email exchange but also can mislead
people into decision chains that tack toward producing software that
is bigger, slower, harder to maintain, lacking in functionality or
worse by most weightings of external benefits that people would
accept.
Getting back to the topic of /dev devices without a constant
binding to hardware devices, a device having at least a
context-depenedent binding goes back as far as /dev/tty. Being able
to define a new serial device with open and ioctl have been in the
Linux kernel since before devfs ever existed. Non-devfs systems
generally have many device files in /dev that are not actually bound
to any existing devcies. For example, a non-devfs system may have
device files for the first four SCSI disks even on a system that has
no SCSI disks. In fact, such a device file may become valid later if
a USB disk is plugged in. User programs seem to be working OK with
the non-constance of a device file's binding to a specific hardware
device (i.e., there has not been some big unintended consequence that
has caused systems lock up when they boot or when it's time to run
fsck or after 8 hours of use or whatever). So, the costs of this
approach that I can think of seem pretty small.
Being able to open a device and then using ioctl's to define
it (such as is currently the case in serial and loop devices) creates
a programming interface that is more easily ported to other operating
systems that don't have /sys and but do have open and ioctl. The
existing approach is also more capitable with versions of Linux that
lack /sys.
Before these ioctl's are run on a serial device to set the
UART type, interrupt and IO port, the kernel does not necessarily know
that there is a UART at a particular IO location, what type it is and
what interrupt it is associated with. So, it sounds like a /sys
interface would be more kernel code than the current scheme without
solving any real problem or delivering any real benefit that I see.
Also, the dynamic configuration of serial ports with setserial
is code that has been widely used for a long time, so its reliability
should be pretty good.
So, it seems to me that the expected reliability,
compatability, kernel code size and user code size benefits are likely
to exceed those of defining some new creation process using /sys. If
you disagree, then please come up with some specific proposal (even if
just for purposes of example), list these trade-offs and whatever
others you perceive, and then we can discuss which approach each of
thinks provides the most benefit on balance.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / 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."
On Fri, Mar 14, 2003 at 11:06 AM, Adam J. Richter wrote:
> On 2003-03-14 at 15:23:50, David Woodhouse wrote:
> >On Mon, 2003-03-10 at 18:25, Bryan Whitehead wrote:
> >> [snip]
> >> > 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.
> >>
> >> are you saying there is a way to force devfs to make more
> >> entries in /dev/tts/ without any hardware being attached
> >> to the entries? Then i can use setserial? so on boot I'd
> >> have 4 entries in /dev/tts ?
>
> >Don't do this. The whole concept of opening a device node
> >for a device which is _absent_, then doing magic ioctls on
> >it to make the driver probe for the hardware, is utterly
> >bogus.
>
> >Fix it properly instead -- disallow opening of a /dev/ttySx
> >node with uart type unknown, and implement a proper way to
> >tell the serial driver 'please look for a device _here_',
> >via sysfs or something.
>
> I don't know what you mean by "is utterly bogus." You need to
> explain why you think this practice results in a larger kernel
> footprint, lower throughput, longer latency, larger object or source
> code size, or is worse by some other objective external metric when
> compared to a specific alternative (another element you seem to have
> omitted).
>
> This is a frequent problem that I see in many public technical
> discussions. Using intimidation words like "is utterly bogus" to
> cover for not stating real technical reasons not only wastes peoples
> time in reading an unnecessary email exchange but also can mislead
> people into decision chains that tack toward producing software that
> is bigger, slower, harder to maintain, lacking in functionality or
> worse by most weightings of external benefits that people would
> accept.
>
> Getting back to the topic of /dev devices without a constant
> binding to hardware devices, a device having at least a
> context-depenedent binding goes back as far as /dev/tty. Being able
> to define a new serial device with open and ioctl have been in the
> Linux kernel since before devfs ever existed. Non-devfs systems
> generally have many device files in /dev that are not actually bound
> to any existing devcies. For example, a non-devfs system may have
> device files for the first four SCSI disks even on a system that has
> no SCSI disks. In fact, such a device file may become valid later if
> a USB disk is plugged in. User programs seem to be working OK with
> the non-constance of a device file's binding to a specific hardware
> device (i.e., there has not been some big unintended consequence that
> has caused systems lock up when they boot or when it's time to run
> fsck or after 8 hours of use or whatever). So, the costs of this
> approach that I can think of seem pretty small.
>
> Being able to open a device and then using ioctl's to define
> it (such as is currently the case in serial and loop devices) creates
> a programming interface that is more easily ported to other operating
> systems that don't have /sys and but do have open and ioctl. The
> existing approach is also more capitable with versions of Linux that
> lack /sys.
>
> Before these ioctl's are run on a serial device to set the
> UART type, interrupt and IO port, the kernel does not necessarily know
> that there is a UART at a particular IO location, what type it is and
> what interrupt it is associated with. So, it sounds like a /sys
> interface would be more kernel code than the current scheme without
> solving any real problem or delivering any real benefit that I see.
>
> Also, the dynamic configuration of serial ports with setserial
> is code that has been widely used for a long time, so its reliability
> should be pretty good.
>
> So, it seems to me that the expected reliability,
> compatability, kernel code size and user code size benefits are likely
> to exceed those of defining some new creation process using /sys. If
> you disagree, then please come up with some specific proposal (even if
> just for purposes of example), list these trade-offs and whatever
> others you perceive, and then we can discuss which approach each of
> thinks provides the most benefit on balance.
>
Hi Adam,
The largest gotcha that I am aware of for the PCI/setserial command
combination is the inability to automatically "follow" the card when
its address changes due to adding or removing an unrelated PCI device.
Even so, the system is unlikely to crash because the driver checks the
LSR register for impossible values and cuts off access when the UART
is not present.
Setserial was designed in the days of ISA serial cards which did not
have the moving-target issue.
I agree that a better interface for dynamic serial port configuration
is needed. In particular, I would like to see coverage of memory mapped
cards. However (comma) do we want to destabilize 2.4 to make fundamental
changes to the serial driver configuration interfaces? Probably not. If
it's really a 2.5 issue, then we should look at Russell King's redesign
in 2.5 and make constructive suggestions (patches) for 2.5. (_after_
reading the LKML archive threads about it)
Anybody know of any other (worse) technical issues with PCI/setserial
on the 2.4 kernels?
Cheers,
Ed
----------------------------------------------------------------
Ed Vance edv (at) macrolink (dot) com
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------
On Fri, Mar 14, 2003 at 11:49:54AM -0800, Ed Vance wrote:
> Anybody know of any other (worse) technical issues with PCI/setserial
> on the 2.4 kernels?
Please note that one of the things I've recently done is to put a lot
of effort into re-working the PCI serial code in 2.5, hopefully without
breaking too much other stuff. It works here with my, ah hem, limited
PCI serial devices.
One of the areas I've tried to improve is our "port guessing" algorithm.
Hopefully, this will allow more serial cards to just work like the one
which started this thread, but only time will tell if this is successful.
It hasn't hit Linus' tree yet, so please don't go looking there for it
yet.
I'm also not going to suggest backporting it to 2.4 either, but if some
one is feeling brave enough, they're welcome to try (this is what Open
Source is all about!) 8)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Fri, 14 Mar 2003 at 11:49:54, Ed Vance wrote:
>The largest gotcha that I am aware of for the PCI/setserial command
>combination is the inability to automatically "follow" the card when
>its address changes due to adding or removing an unrelated PCI device.
>Even so, the system is unlikely to crash because the driver checks the
>LSR register for impossible values and cuts off access when the UART
>is not present.
I would expect that setserial should only be used in cases
where this information is not reliably determinable by the kernel
through hardware device ID facilities, such as what we have in PCI,
USB, etc. If that is not already the case, it should be
straightforward to fix in the kernel sources, which seemed to be most
of what the "3 Serial issues up for discussion" thread was about
(thanks for the pointer). There was tangential mention in that thread
of a "/proc/serialdev" interface, but nobody really identified any
real benefit to it over the existing "uart: unknown" system.
Anyhow, my primary point in this discussion is just to say
that, as far as I can tell, devfs does not impede the serial driver
from doing what Ted Ts'o seemed to be describing.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / 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."
On Fri, Mar 14, 2003 at 12:28:47PM -0800, Adam J. Richter wrote:
> There was tangential mention in that thread
> of a "/proc/serialdev" interface, but nobody really identified any
> real benefit to it over the existing "uart: unknown" system.
There is one benefit, which would be to get rid of some of the yucky
mess we currently have surrounding the implementation of stuff which
changes the port base address/irq.
Currently, we have to check that we're the only user, shutdown, tweak
stuff, hope it all goes to plan, and start stuff back up again. If
something fails, we have to pray we can go back to the original setup
without stuff breaking. If that fails, we mark the port "unknown".
All of this would be a lot simpler if we didn't have the port actually
open at the time we change these parameters. We could just lock the
port against opens, check no one was using it, tweak the settings,
and release the port. If the changes fail, just report the failure.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Fri, 14 Mar 2003, Russell King wrote:
>On Fri, Mar 14, 2003 at 12:28:47PM -0800, Adam J. Richter wrote:
>> There was tangential mention in that thread
>> of a "/proc/serialdev" interface, but nobody really identified any
>> real benefit to it over the existing "uart: unknown" system.
>There is one benefit, which would be to get rid of some of the yucky
>mess we currently have surrounding the implementation of stuff which
>changes the port base address/irq.
>Currently, we have to check that we're the only user, shutdown, tweak
>stuff, hope it all goes to plan, and start stuff back up again. If
>something fails, we have to pray we can go back to the original setup
>without stuff breaking. If that fails, we mark the port "unknown".
>All of this would be a lot simpler if we didn't have the port actually
>open at the time we change these parameters. We could just lock the
>port against opens, check no one was using it, tweak the settings,
>and release the port. If the changes fail, just report the failure.
When I filter out prejudicial terminology like "yucky mess",
"pray", "just", etc., I don't see a convincing explanation of how one
approach is going to result in a lower line count, fewer branches,
smaller kernel footprint, faster execution, new capabilities or any
other relevant measure that I can think of in comparison to the
existing approach.
As far as only one user having the port open when doing an
ioctl to define the port, it is not clear to me that a /proc-like
interface would do it in less code. Given that you still have the
possibility of undefining serial ports on the system, the issue of
making sure that there is only one user with the port open in the case
of deletion should still be approximately the same under either
approach. Perhaps I'm talking this to death. Maybe if you post a
diff that is a net reduction of lines of code, that would clarify
things more easily than discussing it further before that point.
Anyhow, I'm not involved in serial driver development. I
just think that if we try to avoid prejudicial language, we're more
likely to make more better decisions by whatever measures we agree on
(or expose differences in what is "better" in different contexts). I
know it's a pain to do and I'm not trying to create an infinitely high
standard of proof or formality. I'm just suggesting a little more
checking of our own objectivity.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / 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."
On Fri, Mar 14, 2003 at 4:03 PM, Adam J. Richter wrote:
> On Fri, 14 Mar 2003, Russell King wrote:
> >On Fri, Mar 14, 2003 at 12:28:47PM -0800, Adam J. Richter wrote:
> >> There was tangential mention in that thread
> >> of a "/proc/serialdev" interface, but nobody really identified any
> >> real benefit to it over the existing "uart: unknown" system.
>
> >There is one benefit, which would be to get rid of some of the yucky
> >mess we currently have surrounding the implementation of stuff which
> >changes the port base address/irq.
>
> >Currently, we have to check that we're the only user, shutdown, tweak
> >stuff, hope it all goes to plan, and start stuff back up again. If
> >something fails, we have to pray we can go back to the original setup
> >without stuff breaking. If that fails, we mark the port "unknown".
>
> >All of this would be a lot simpler if we didn't have the
> port actually
> >open at the time we change these parameters. We could just lock the
> >port against opens, check no one was using it, tweak the settings,
> >and release the port. If the changes fail, just report the failure.
>
> When I filter out prejudicial terminology like "yucky mess",
> "pray", "just", etc., I don't see a convincing explanation of how one
> approach is going to result in a lower line count, fewer branches,
> smaller kernel footprint, faster execution, new capabilities or any
> other relevant measure that I can think of in comparison to the
> existing approach.
>
> [ snip ]
Hi Adam,
Oh, but he _did_ give you information about such things. You filtered out
the real message. Allow me to expand the macros ...
yucky mess = referenced area has an unnecessarily complex control
structure. (more branches & code, slower ...)
just = fundamental simplification of the algorithm. (less code and
branching needed because less to do, smaller, faster ...)
hope, pray = referenced area can generate complex errors that cannot
be handled efficiently due to architectural limitations.
(more local error handling code and branching, bigger, slower ...)
expert opinion != prejudicial speech.
Read it again. You'll get the hang of it :-)
Cheers,
Ed