| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 4 Apr 2007 08:47:36 +0100 From: Russell King <rmk+lkml@....linux.org.uk> To: David Miller <davem@...emloft.net> Cc: alan@...rguk.ukuu.org.uk, paulus@...ba.org, dwmw2@...radead.org, linuxppc-dev@...abs.org, benh@...nel.crashing.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers. On Tue, Apr 03, 2007 at 06:21:25PM -0700, David Miller wrote: > From: Alan Cox <alan@...rguk.ukuu.org.uk> > Date: Wed, 4 Apr 2007 02:19:24 +0100 > > > > I totally agree with Paul, the onboard serial device should get > > > ttyS0 regardless of what hardare is used to drive it. > > > > Thats between you and udev. > > That might be true when udev exists, but it doesn't for the console > specification on the kernel command line. FACT: you can only have one struct console with one name. FACT: If you have two struct consoles using the same name, the driver which wins the priviledge of console is unpredictable. FACT: there is no way to know at any particular driver registration time how many "generic" serial ports will be available - as required for the chardev and tty layers. There are very real issues that need fixing deep within the kernel before you can even think about the possibility of *PROPERLY* supporting all serial ports beneath one namespace. Before someone whinges "we did it in 2.4" my answer is: yes, you hacked around the problem in 2.4 creating an utter mess in the process. If you want to see what an utter mess pushing all serial ports towards ttyS* creates in 2.5 kernels (which will be similar for 2.6), look at these patches: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1427/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1428/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1429/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1431/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1432/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1433/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1435/2 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=1436/2 Moreover, note that the serial core is statically configured with the *maximum* number of ports it will ever support. Tough luck if you're a distro and wanting to allow users to support multi-port serial cards. Since we've been where we are for years and years, my take on this subject has always been: we should *not* abuse any of the existing allocations. If we want to create a single namespace for serial ports we should obtain a *new* allocation and migrate drivers over to that namespace, avoiding any bastardisation of existing drivers. Modulo fixing the very real issues mentioned above first. Feel free to continue whinging about it for a few more years. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists