geom_label verbosity patch

[Ivan Voras]

Pawel Jakub Dawidek wrote:
> On Thu, Apr 23, 2009 at 02:15:14PM +0200, Ivan Voras wrote:
>> Pawel Jakub Dawidek wrote:
>>> On Thu, Apr 23, 2009 at 01:52:01PM +0200, Ivan Voras wrote:
>>>> Hi,
>>>>
>>>> I want to ask for a community review of these patches:
>>>>
>>>> http://people.freebsd.org/~ivoras/diffs/geom_label_errlevel.txt
>>>> http://people.freebsd.org/~ivoras/diffs/glabel.8_errlevel.txt
>>>>
>>>> The intent is to make glabel less chatty on detection of new providers,
>>>> etc. [...]
>>> This is on purpose, so don't change that. One can always set it to -1.
>> Possible, but it would make it unique among other GEOM classes.
> 
> Almost every GEOM class informs about creating providers, so what you
> suggest is inconsistent.

I think you feel more strongly about the topic than it warrants it -
"almost every" is not "every" and glabel is technically a slicer just
like gpart - you wouldn't like gpart to announce as it creates da0s1a,
da0s1b, da0s1c, etc.? Besides, the trend is toward reducing the amount
of generic (redundant, repeatable) information on boot. :)

What could be possibly more useful is to create a framework that would
output only "diff" messages - i.e. that shows that I had da0s1a or
ufs/mylabel when I booted last time, and I suddenly lost it now. But
this is non-trivial for many reasons, including how and where to store
the information and what to do with hot-plug devices. Maybe devd could
take care of all these announcements?

>>> This way we not only make it less chatty again, but also not to pollute
>>> /dev/.
>> One way to lessen it is to stop creating individual directories for each
>> label class, as discussed before.
> 
> How is it going to reduce number of providers in /dev/?

I was thinking about the "ls /dev" case. What other thing would be a
concern in the number of entries in what's essentially a very light
weight memory file system whose content are nodes of several bytes in
size (less than 100 bytes if I count them correctly, +vnodes, labels,
book-keeping)?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090423/d12839b9/signature.pgp