Jaunty config changes: Reduce CONFIG_LEGACY_PTY_COUNT to 0

Scott James Remnant scott at canonical.com
Tue Dec 23 16:08:53 UTC 2008


On Tue, 2008-12-23 at 10:34 +0000, Andy Whitcroft wrote:

> On Mon, Dec 22, 2008 at 05:28:09PM +0000, Scott James Remnant wrote:
> > On Mon, 2008-12-22 at 17:16 +0000, Andy Whitcroft wrote:
> > 
> > > I am not convinced that if we set CONFIG_LEGACY_PTY_COUNT that the user
> > > will be able to use these devices at all.  In the init function we check
> > > if this value is <= 0 and if so we abort initialising the driver:
> > > 
> > > static int legacy_count = CONFIG_LEGACY_PTY_COUNT;
> > > [...]
> > > static void __init legacy_pty_init(void)
> > > {
> > >         if (legacy_count <= 0)
> > >                 return;
> > > [...]
> > > 
> > You snipped the all-important line right below the first one:
> > 
> > module_param(legacy_count, int, 0);
> > 
> > This is a parameter that has CONFIG_LEGACY_PTY_COUNT as its *default*,
> > not hard-coded value.
> > 
> > You can boot with pty.legacy_count=... and that will change the value of
> > legacy_count, so when the driver init()s, it will be > 0
> 
> My comment was in the context of the irc conversation (which isn't
> obvious I know) where the discussion was that the user could simply
> mknod some files.  You are correct that if they use the kernel command
> line they can get it to init.  And if that is the recommended use mode
> it makes sense to go to 0.
> 
The user still can mknod some files?

All the init() section does is register a whole bunch of pty objects; if
it is skipped, all that means is that the pty objects aren't registered.

If you mknod() them yourself, the pty driver itself is still loaded, so
they still function.

pty's have fixed major/minor numbers and don't need dynamic
registration, remember.

Scott
-- 
Scott James Remnant
scott at canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20081223/5875b33d/attachment.sig>


More information about the kernel-team mailing list