> > [...]
> > > That is a flat out lie. With devfs, you can change the permissions
> > > just fine (with chown/chmod/chgrp/whatever utility you feel like
> > > using that works with other normal filesystems), and they will stay
> > > until the devfs filesystem is unmounted, and possibly even until you
> > > reboot, though I haven't tried that, and doubt it a bit... You could
> > > expect almost no less from a ramdisk (though it would stay until
> > > reboot on a ramdisk unless you reconfigured the ramdisk), or anything
> > > else that is stored on volatile media.
> > But you say, pemissions are permanent. What is it with you, is "permanent"
> > like in "stays the same unless changed" somehow hard to grasp?
> Excuse me? I'm not sure how this applies to what I said, but if you want
> "permanent" permissions, use devfsd and update your config file with the
> new permissions, or chmod the devices in an rc script, or even create the
> devices with the right permissions in an rc script (yes, you can use mknod
> to your hearts content)
OK, I see the code for chmod(1) now:
if(file is named /dev/whatever) { /* This is _hard_ to find out */
go update /etc/devices.perms
}
else {
...
}
Never thought of that brilliant solution. Just have to fix the obvious race
in there. And think about what to do if /etc/devices.perm is inaccessible
(gone, broken, ...).
[...]
> > > What if you don't like the permissions MAKEDEV gives? devfs comes with a
> > > set of permissions that is not unlike the ones in the MAKEDEV script; it
> > > doesn't just blindly choose '777' as the permissions.
> > Change MAKEDEV? Write a MAKEDEV that uses /etc/makedev.conf as default
> > permissions when creating devices?
> And this is different from using devfsd and changing the devfs config
> file HOW? Please do enlighten me.
Zero kernel impact sound a bell?
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/