Re: [PATCH 1/3] [RFC] genhd: add a new attribute in device structure

From: Kay Sievers
Date: Fri Jun 17 2011 - 11:57:35 EST


On Fri, Jun 17, 2011 at 17:41, Douglas Gilbert <dgilbert@xxxxxxxxxxxx> wrote:
> On 11-06-17 01:25 AM, Greg KH wrote:
>> As for "expediency", it has been a full year since the last time this
>> was proposed. ÂAll userspace tools that would need to be changed to
>> implement this in userspace have had updates released for them in that
>> year, and the changes needed to make to them could have been done
>> already.
>
> Could you elaborate taking one user space tool as an
> example and tell us what changes you think should be
> made?
>
> Are you talking about low level tools such as hdparm,
> smartmontools and mine or tools further up the "food
> chain"?

I think the only thing really missing is a smarter 'syslog' that has
context, and not just a stream of almost random free-text packets.

Ideally the main source would be a _structured_ and properly machine
readable error/debug log from the kernel, maintained in userspace as
an indexable database, and constant merging of userspace state
information into it.

Debug/error messages from the kernel would need proper classification
and if needed can carry additional data structures, even binary data,
that contain dumps of sense results or firmware data.

I doubt there can be any really useful kernel only solution to
enterprise storage needs. Especially not based on printk().

I'm sure, we should really start to think in that direction instead of
extending things that are unlikely to solve the underlying problem
ever.

Userspace tools can already query the udev database very easily, it's
almost free, no IPC, no fork() involved, it's just a few libudev calls
which read files out of tmpfs. If they want to show names they can do
that already today. Making the kernel decide which one of the names is
the single one to choose, just can't work, I think.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/