Prev: tracing, powerpc: Add data parameter to powerpc-specific tracepoints
Next: [PATCH] timer.c: fix kernel-doc warning
From: Kay Sievers on 25 May 2010 00:50
On Mon, May 24, 2010 at 20:08, Alan Ott <alan(a)signal11.us> wrote:
> Several weeks ago I had need of libudev, and was unable to find very
> much documentation for it on the web.
>
> I have created a guide on how to use libudev, which also provides some
> background information on /dev, Sysfs, and why this kind of thing is needed.
>
> Please check it out and provide comments, as I'm sure there are things
> which I have gotten wrong or omitted.
>
> 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. 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.

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.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Ott on 27 May 2010 22:30
Kay Sievers wrote:
> On Mon, May 24, 2010 at 20:08, Alan Ott <alan(a)signal11.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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Kay Sievers on 28 May 2010 13:10
On Fri, May 28, 2010 at 04:28, Alan Ott <alan(a)signal11.us> wrote:
> 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?

Nothing really. They would not be added today. It's from the time
everybody added their favorite stuff to sysfs, and nobody had a real
idea in which direction the stuff was supposed to go. :)

We only need "add"/"remove" and "move" for renames or re-parenting,
and "change" when stuff changes.

The "online"/"offline" are not useful at all, and ideally should just
use "change" for their state and pass the state with variables or
sysfs files.

No new subsystem should ever use these events.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: tracing, powerpc: Add data parameter to powerpc-specific tracepoints
Next: [PATCH] timer.c: fix kernel-doc warning