linux-kernel - Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 4 Apr 2007 19:55:30 +1000
From:	Paul Mackerras <paulus@...ba.org>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	linuxppc-dev@...abs.org, dwmw2@...radead.org,
	alan@...rguk.ukuu.org.uk
Subject: Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers.

Russell King writes:

> FACT: you can only have one struct console with one name.

That could be solved by having the struct console at the generic
serial driver level rather than in the individual port drivers.

> 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.

I think the thing that davem and I have in common is that we have a
data structure that the firmware gives us that (at least) enumerates
all of the on-board serial ports for us, thus we *can* know very early
in the boot process how many "generic" serial ports will be available.

> 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.

I don't actually want to do that; I'm perfectly happy for various
kinds of plug-in cards to each have their own namespace.  If you're
plugging in a Cyclades card for instance I think it's quite reasonable
for the ports to be named /dev/ttyCn.

It's the built-in serial ports on the motherboard where I think the
user should not have to know what sort of chip was used to implement
the serial port.  We don't require users to know whether the
manufacturer used an 8250 or a 16450 or a 16550, so why should it
matter if the manufacturer used an 8530?

BTW, are you still maintaining the serial layer?

Paul.
-
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/