linux-kernel - Re: [RFC] User Guide for Sysfs and libudev

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: <4BFF2A33.8060504@signal11.us>
Date:	Thu, 27 May 2010 22:28:03 -0400
From:	Alan Ott <alan@...nal11.us>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	linux-kernel@...r.kernel.org, linux-input@...r.kernel.org
Subject: Re: [RFC] User Guide for Sysfs and libudev

Kay Sievers wrote:
> On Mon, May 24, 2010 at 20:08, Alan Ott <alan@...nal11.us> wrote:
>> The guide can be found here:
>>    http://www.signal11.us/oss/udev/
>>     
>
> Enumeration and monitoring should be in one example, I guess -- that's
> what people are supposed to do today.
Hi Kay,

The example .c file does do both in the same example. The document talks
about them separately, for simplicity, since the lead-in section
directly makes the case for enumeration. I added a section of text (see
below) which mentions this.
> Before starting to enumerate,
> software should subscribe to events. This makes the handle
> coldplug/hotplug properly, makes it handle duplicate events properly,
> and all other sorts of cases, which software should handle today.
>   
This makes sense. I've changed the example .c program so that it sets up
the monitoring interface before enumerating. I also added a section to
the document talking about the reason for doing this first. The new
section is the one between the second code block and the "Output" section.
> Also "change" is not necessarily a "property" change, it can be any
> event, that a device has changed its state, it will only in  a few
> cases be visible in /sys. The most prominent example is "media
> changed" event for SCSI devices, and we forward them to the block
> device. There will never change anything in /sys before or after the
> event.
>   
I've changed the text in the document appropriately.

Also, would you please give me some text which describes the "online"
and "offline" events? What types of devices do these come from? Are
there any other types of events which are not listed?

Thanks for reading my document, and thanks for your insightful comments.

Alan.


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