Date: Wed, 26 Nov 1997 12:53:19 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: S?ren Schmidt <sos@FreeBSD.dk> Cc: hackers@FreeBSD.ORG Subject: Re: DEVFS/SLICE passes milestone Message-ID: <Pine.BSF.3.95.971126124157.3379D-100000@current1.whistle.com> In-Reply-To: <199711262036.VAA06175@sos.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 Nov 1997, S?ren Schmidt wrote: > In reply to Julian Elischer who wrote: > > Unfortunatly the existing code is inherrently broken by design. > > Now you tell us :(, that is the exact reason for our reservations > on what goes in and what does not nowadays.... It's not DEVFS that's broken, it's the existing slice system. it's too intertwined with itself. It's close to impossible to untangle it enough to make things happen in the order needed. an example.. slices are only noticed when you open the device. How do you open /dev/rsd0a if you don't know that it exists? The present code works because /dev/has entries that are always present, whether or not the system knows that the slice exists. with dynamic assignment of new slice types and partitionning schemes (e.g. raid) the device node may not exist.. then how do you open it to find that the slice exists? Dynamic devices are inherrently incompatible with devices that only make their nodes when you OPEN them. (you can't see the device because it isn't open, you can't open it becasue you can't see it) The new code is a LOT easier to read than the existing SLICE code as it breaks the functionality up into handlers, for each kind of slice so it's not all mashed in together. it allows us to dynamically and easily add new layers e.g. raid, mirroring etc. with minimal work. The DEVFS changes are separate, but as I don't run a diskless system, I cannot go further with DEVFS until I have the SLICE code fixed. Now that that is going, I have a chance of getting DEVFS production grade. > > > After discussing this with PHK we agreed that the two changes were > > intertwined. > > Well, depends on viewpoint, but I'll buy that... PHK tried to rewrite the slice code, but ended up needing a devfs (he wrote a 'make my device-daemon' (poor-man's devfs) I tried to get devfs up to production quality, but needed a new SLICE layer. The obvious answer is to merge the two efforts. > > > DEVFS works fine without the slice changes, except that > > you can't do disk partitions because of the broken-ness. > > i.e it works fine for diskless systems. > > > > You can do devfs without SLICES but it won't help you too much because of > > this. > > > > I have been consulting others on this as I go.. > > I know :), I just wanted to get this straight, we don't want a new > "inherrently broken by design" subsystem again. devfs isn't inherrently broken. it's just incompatible with BDE's slice code. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end > .. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.971126124157.3379D-100000>