Well, if they don't use them, then they have to determine the defaults
inside the driver. Then somebody else notices it and it gets fixed. Nothing
will be broken if they don't use it. And between a module.txt and a
devfs.txt and everything else in Documentation, new developers should get
the hint.
> Another problem is that you'll want to copy over .devperms from one
> kernel to the next, just like you copy .config around. You'll need to
> make sure that the script *merges* .devperms and defdevperms together
> into a new .devperms before generating devperm.h.
That's _exactly_ what make config does with defconfig and .config. I
envisage this working VERY similarly.
> To make the configuration easier, you could generate .devperms from
> the existing devices in /dev.
No reason not to provide a script to extract that info from an old style
/dev or a devfs or anything else. The defdevperms file should contain a
very reasonable set of defaults (as MAKEDEV does now).
> > #define MODULE_DEVPARM(_drv) \
> > static int dev_owner = DEVPERM_##_drv##_owner; \
> > MODULE_PARM(dev_owner, "i"); \
> > static int dev_group = DEVPERM_##_drv##_group; \
> > MODULE_PARM(dev_group, "i"); \
> > static int dev_mode = DEVPERM_##_drv##_mode; \
> > MODULE_PARM(dev_mode, "i")
>
> Erk! Getting complicated.
But not for anybody writing devices. That define will be in devparm.h and
that's it. Only one line for the module writer to add:
MODULE_DEVPARM(lp);
That pulls in everything. All the complicated bits are done once to provide
the service. Then devlopers use it.
> I personally think that doing:
> # chmod go= /dev/lp0
>
> is really easy and obvious. And the saving script can be as simple as
> using find and tar together. The restoring script only needs to call
> tar. Ensuring persistence is really easy.
True. But I still would like a system where my kernel configuration gives
me a pretty decent system. This completes the configuration of the kernel.
You tell it which drivers you want to include and you can change the
permissions that they default to.
I would just like a system that doesn't need a whole lot of stuff to happen
at boot to setup devices. I'd far prefer a kernel that gives devices that I
want how I want.
We have an oppurtunity to do a whole lot of things and each thing we've
brought up doesn't break anything. The devparm thing only affects those
devices that choose to do it. And slowly we suck that into all drivers in
the kernel. Another desirable outcome is that it will result in a
consistent treatment of permissions. MODULE_PARAM has done that for the
carnage that used to be module parameters.
We're going to have each driver picking its own defaults. It can't be a Bad
Thing to allow the kernel builder a way to configure that. I've always been
annoyed that some things can't be configured in the kenrel. Like parallel
ports. You became able to do it through modules but without modules you
_had_ to edit lp.c to tell the driver which interupts to use. No choice.
Even if sysadmins ignore devperms, they continue to be able to do the
persistence your way. But a lot of people have been concerned about this
persistence mechanism. I'm hoping this will make devfs even more
attractive.
-- [======================================================================] [ Kevin Lentin Email: K.Lentin@cs.monash.edu.au ] [ finger kevinl@fangorn.cs.monash.edu.au for PGP public key block. ] [ KeyId: 06808EED FingerPrint: 6024308DE1F84314 811B511DBA6FD596 ] [======================================================================]