Date: Fri, 29 May 1998 23:58:30 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Mike Smith <mike@smith.net.au> Cc: Eivind Eklund <eivind@yes.no>, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... Message-ID: <2867.896511510@time.cdrom.com> In-Reply-To: Your message of "Fri, 29 May 1998 22:31:21 PDT." <199805300531.WAA00926@antipodes.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Yes, but you can't *look*at* the template mount to find out what these > numbers *are*. Why *not*? :-) If the devfs subsystem gets a mount request to go instantiate cdev foo0 with 1/12, you still have a pointer to your "invisible master" containing its own list of devices, one of which, I'd hope, would have a major/minor of 1/12. What's to stop you from then cloning the entry back over? I'm also not *against* matching on names, that's fine, I'm simply arguing that we can never really know just what kinds of custom sysadmin tools are out there, and if we're handed a request through mknod(2) for something which used to work, we should probably try and make it continue to work so that this tool doesn't suddenly break the day we throw the switch to devfs. This isn't as rare a scenario as one might think, either, our very own dear sysinstall having *mucho* internal knowledge of major/minor values and the devices they represent. Sure, I'll change sysinstall or its replacement well before the time comes because I will be well warned, but not everyone keeps that closely up to date on our progress and I can well imagine other tools, some perhaps even derived from sysinstall, out there doing overly incestuous things with major/minor numbers which will need more time to make the transition. Implementing backwards-compatibility directly at the mknod(2) level means we don't have to even think about how people might be abusing things in system applications, they'll Just Work for whatever set of dev_t assignments we last had before devfs replaced it. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2867.896511510>