Date: Sat, 14 Feb 1998 04:04:48 -0200 (EDT) From: Joao Carlos Mendes Luis <jonny@coppe.ufrj.br> To: mike@smith.net.au (Mike Smith) Cc: jonny@coppe.ufrj.br, julian@whistle.com, mike@smith.net.au, phk@critter.freebsd.dk, committers@FreeBSD.ORG Subject: Re: devfs persistance Message-ID: <199802140604.EAA06373@gaia.coppe.ufrj.br> In-Reply-To: <199802140523.VAA18230@dingo.cdrom.com> from Mike Smith at "Feb 13, 98 09:23:17 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
#define quoting(Mike Smith) // > 1) What will be the impact on hand-created devices ? Will still be possible // > to simply mknod some file on some dir and use it ? // // Not effectively, no. I was afraid of that. :) I have to think a a lot more on this before discussing at the current levels I've seen until now. // > I don't like the // > ideia of having to use DEVFS on chrooted environments. In such // > environments not all devices should be seen, and the permissions // > could be even different from the defaults. // // This is what we have just been discussing. We're aware of the // requirement; what has been left out in your consideration? Just agreeing with the consideration, and wondering how could this be done without support of traditional mknod. // > 2) What's the practical meaning of "turning DEVFS default" ? // // I have no idea. Gulp. :) // > 3) Will DEVFS in any sense make major numbers random ? if so, my #1 // // Yes. // // > question is already answered. Not to hardcode device number is // > good, but letting the kernel choose them on the fly is not good. // // Why is this? Do you have any reasoning beyond personal preference? This makes you fully dependant on a devfs, but now I see it your intention from the beginning. // > I like, for example, the Solaris' /etc/name_to_major approach. // // That's just as bad as MAKEDEV in the first place. devfs would still have the on-the-fly-device behaviour, without need to remove mknod devices. Maybe I should forget everything I've learnt of Unix devices before going on this discussion. // > Being said the above, I think I like Mike Smith's approach of // > /dev/devperm. But there's no need of a backing store. Just // // There is. // // > put a "cat /etc/minor_perm > /dev/devperms" right after mounting // > /dev. // // If you want to do it this way, you can. But bear in mind that this // approach has the following flaws: // // - you forgot /dev/devrules What's the sintax you propose for these two files ? // - if you only have one file, /etc/devperms, how can you have multiple // devfs mounts with different permissions? Hmmmmm... Two specs, for two completely independent device trees. It's getting better. But I still need to mount each one. What if I want a device together with other files, or inside a special user account ? Is this just bad practice ? // > If you need any change, just edit the file and cat it again. // // No. Definitely not. devperms is for single-device overrides, and its // contents will respond to chown/chmod operations to avoid violating POLA. Sorry, I missed the meaning of POLA. But in this point I agree with PHK in the sense that I want the devices in a known condition after booting. When a user logs, not only his terminal gets owned by him, but /etc/fstab could be used to add even more rights. If my system crashes or reboots without him logging out, I would prefer not to keeps his rights. It's not done today, anyway, so it's not a big problem. // > The file could be read to get the current configuration, but a // > change into the mounted system would not reflect into it. Or maybe // > the could be another device that would read the current config. // > Maybe a sysctl is needed for the name_to_major approach, since it // > needs to be loaded before mounting. // // It is likely that major numbers will disappear at some stage in the // not-too-distant future. Gulp ^ 2 ! What if I want to call a device by another name ? I want to have the choice to call /dev/fd0 as /dev/floppy. Why ? Because I want, or maybe because I have a program without sources that needs such a name and does not accept symlinks. This could get worst with emulation. What if I get a commercial Linux program to handle some serial device that asks for /dev/tty00, and I only have /dev/ttyd0 ? A bad program, surely, but possible. I like to use /dev/mouse and /dev/ups as symlinks to the real serial devices. And so on. Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802140604.EAA06373>