Date: Mon, 8 May 2000 17:41:27 +0930 From: Greg Lehey <grog@lemis.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: FreeBSD-arch@FreeBSD.ORG Subject: Re: Tidiness or kernel bloat? (was: Support for bootable Vinum file systems: please review) Message-ID: <20000508174126.U61921@freebie.lemis.com> In-Reply-To: <16522.957772628@critter.freebsd.dk> References: <20000508083331.A61488@freebie.lemis.com> <16522.957772628@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 8 May 2000 at 9:57:08 +0200, Poul-Henning Kamp wrote: > 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. That was the intention. If you find it's useful for something else as well, what's the problem? > 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. It does that now. Look at the patch. >> 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. Should I be penalized for that? In general, the kernel should have access to everything that userland has access to. Would you object to this if I were looking for statistics instead? > 2. The userland access is a well-defined API. I'm using the same data structures. What more interface do you want? > 3. You want to open the implementation to your can grovel around in > the entrails of devstats implementation. This is very much a matter of definition. > 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. Have you looked at the code? These "internals" are exactly the data that we hand to userland. I could, of course, write a devstat function which makes a copy of the data, the way it hands it to userland, but what's the point of that? And why should passing a different structure be less untidy, just because it was specially built for this purpose? This smells of NIH. While I still disagree with your interpretation, Justin made a valid point: the real way to do this is with a callback. How about a compromise: we leave the code the way it is for now. Later, when you implement the callbacks you've been talking about, I'll modify things to use them instead, completely removing any reference to devstat. OK? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers 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?20000508174126.U61921>