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