linux-kernel - Re: [patch 3/3] libata: handle AN interrupt

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] [day] [month] [year] [list]

Message-ID: <460BB94D.8060802@emulex.com>
Date:	Thu, 29 Mar 2007 09:04:13 -0400
From:	James Smart <James.Smart@...lex.Com>
To:	Jeff Garzik <jeff@...zik.org>
CC:	Kristen Carlson Accardi <kristen.c.accardi@...el.com>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	linux-ide@...r.kernel.org, linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: [patch 3/3] libata: handle AN interrupt

Jeff Garzik wrote:
> Fair enough, though I definitely lean towards some use of sysfs / device 
> model for AN-style events specifically.  The media change events are 
> generated by the device, not the transport, and we should definitely 
> have an object in the device model that represents the device (if we 
> don't already).
> 
> I could see transport-based events being delivered to a different 
> endpoint, because transport events differ from device events.
> 
>     Jeff

Sure... although what object the event relates to is really a component of
either the socket (1 per object) or an object identifier within the event
message (1 socket with message headers). The transport, as we use it, really
isn't the object and isn't the one generating the events, it's just a well-known
listening point and serves as a nice library to insulate drivers from the
implementation.

Granted, what's being proposed now is fairly simple, so sysfs works fine.
But if you grow at all, you'll be confronted with the multiple-readers
and payload issues that we had.

-- james
-
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/