Date: Mon, 08 May 2000 09:57:08 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Greg Lehey <grog@lemis.com> Cc: FreeBSD-arch@FreeBSD.ORG Subject: Re: Tidiness or kernel bloat? (was: Support for bootable Vinum file systems: please review) Message-ID: <16522.957772628@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 08 May 2000 08:33:31 %2B0930." <20000508083331.A61488@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20000508083331.A61488@freebie.lemis.com>, Greg Lehey writes: >>> Can you make an alternative suggestion? >> >>>>>> The right way to do it is probably to link the "struct disk"s >>>>>> registered by the drivers with disk_creat() into a list which can >>>>>> be searched. > >You're not very strong on reasoning here. You don't answer my >question: > >>>>> Why should we maintain two lists, just because one is primarily >>>>> intended for statistics? Because one of them is *only* intended to care about statistics. Pretty soon you might see devstat track statistics for all logical disk, ie: ad0s1a, ad0s1b, ad0s1, ad0, and you may see it integrated more into the disk mini-layer. None of these changes would affect other users of devstat (except provide more detail) but all of sudden vinum would need magic fixes to only look for whatever types of devices vinum wants to look for. >Your only objection appears to be: > >>>> No, this is an objection to opening up devstat that way. > >Devstat is already available in userland. What more opening up are >you talking about? You approach appears to only add to kernel bloat. 1. You are not trying to access it from userland. 2. The userland access is a well-defined API. 3. You want to open the implementation to your can grovel around in the entrails of devstats implementation. If you insist on this gross hack, the very least you could do was to add a couple of functions to the devstat code rather than pull all the internals into daylight. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16522.957772628>