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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BANLkTi=G4d4JPyt=Q38bGsQJ2K5VPzOhBA@mail.gmail.com>
Date:	Fri, 17 Jun 2011 17:57:12 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	dgilbert@...erlog.com
Cc:	Greg KH <greg@...ah.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Nao Nishijima <nao.nishijima.xt@...achi.com>,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	jcm@...hat.com, hare@...e.de, stefanr@...6.in-berlin.de,
	yrl.pp-manager.tt@...achi.com
Subject: Re: [PATCH 1/3] [RFC] genhd: add a new attribute in device structure

On Fri, Jun 17, 2011 at 17:41, Douglas Gilbert <dgilbert@...erlog.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/