event sequencing

event sequencing

[Jon Smirl]

I working on adding hotplug monitor change detection code to some
framebuffer drivers. I having trouble with event sequencing.

In my probe function I do a class_simple_device_add() to create the
class entry. Later in the probe function I do
kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); to indicate a
monitor change.

I'm receiving the MOUNT event before the ADD one. How can I control the order?

Even in cases where MOUNT comes after ADD udev has not built my device
nodes yet. My MOUNT app needs to use the device node. This is my
bigger problem.

I'm using RH FC3 but this needs to work on all distributions when finished.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Kay Sievers]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

On Fri, 2005-02-25 at 11:18 -0500, Jon Smirl wrote:
>I working on adding hotplug monitor change detection code to some
>framebuffer drivers. I having trouble with event sequencing.
>
>In my probe function I do a class_simple_device_add() to create the
>class entry. Later in the probe function I do
>kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); to indicate a
>monitor change.

Don't use that function. It is only for the driver core. It will execute
a usermode_helper which is not the way to do new stuff. Use the netlink
events for that: If your application is some low-level stuff, listen
directly to uevents:
  http://www.kernel.org/pub/linux/utils/kernel/hotplug/uevent_listen.c

or if it's desktop stuff, add support to HAL for it.

>I'm receiving the MOUNT event before the ADD one. How can I control the order?
>
>Even in cases where MOUNT comes after ADD udev has not built my device
>nodes yet. My MOUNT app needs to use the device node. This is my
>bigger problem.

Record the events with something like the attached script placed as:
  /etc/hotplug.d/default/00-log.hotplug

and post the result here, if you don't see what's going wrong.

Good luck,
Kay

[-- Attachment #2: 00-log.hotplug --]
[-- Type: application/x-shellscript, Size: 140 bytes --]

Re: event sequencing

[Jon Smirl]

On Fri, 25 Feb 2005 17:53:27 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> >In my probe function I do a class_simple_device_add() to create the
> >class entry. Later in the probe function I do
> >kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); to indicate a
> >monitor change.
> 
> Don't use that function. It is only for the driver core. It will execute
> a usermode_helper which is not the way to do new stuff. Use the netlink
> events for that: If your application is some low-level stuff, listen
> directly to uevents:
>   http://www.kernel.org/pub/linux/utils/kernel/hotplug/uevent_listen.c

What do I use instead of this to generate the netlink event?
kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT);

The user mode helper for monitor change needs to run as root. Do I use
the same /etc/hotplug.d directories for netlink?

Is there a write up on how to use netlink in conjuntion with dbus somewhere?

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Jon Smirl]

On Fri, 25 Feb 2005 17:53:27 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Fri, 2005-02-25 at 11:18 -0500, Jon Smirl wrote:
> >I working on adding hotplug monitor change detection code to some
> >framebuffer drivers.

Here's an exact description of what I'm trying to accomplish...

1) Receive hardware interrupt from monitor change.
2) Device driver generates a hotplug event to trigger running of a
root priv userspace helper
3) Helper uses sysfs attribute write to notify when it is done.
4) Device driver generates a netlink? event to hal to indicate that
new state is available.

I've been reading the hal documentation. I can't see how I can use a
netlink event to trigger running of the root mode helper app. I'm
still trying to locate any write ups on how to use netlink.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Kay Sievers]

On Fri, 2005-02-25 at 16:56 -0500, Jon Smirl wrote:
>On Fri, 25 Feb 2005 17:53:27 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> >In my probe function I do a class_simple_device_add() to create the
>> >class entry. Later in the probe function I do
>> >kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); to indicate a
>> >monitor change.
>> 
>> Don't use that function. It is only for the driver core. It will execute
>> a usermode_helper which is not the way to do new stuff. Use the netlink
>> events for that: If your application is some low-level stuff, listen
>> directly to uevents:
>>   http://www.kernel.org/pub/linux/utils/kernel/hotplug/uevent_listen.c
>
>What do I use instead of this to generate the netlink event?
>kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT);

kobject_uevent()

>The user mode helper for monitor change needs to run as root. Do I use
>the same /etc/hotplug.d directories for netlink?

No, uevents don't do anything by themselves, they are just sent from the
kernel and something that listens to it, can do whatever is needed.
You need your own listener for these events, or add that code to an
existing system wide thing like HAL.

>Is there a write up on how to use netlink in conjuntion with dbus somewhere?

No, but HAL listens for that events, you may look there how device
objects react to netlink events and send meaningful events to the
system-wide bus.

Kay




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Jon Smirl]

On Sat, 26 Feb 2005 01:46:23 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Fri, 2005-02-25 at 16:56 -0500, Jon Smirl wrote:
> >On Fri, 25 Feb 2005 17:53:27 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> >> >In my probe function I do a class_simple_device_add() to create the
> >> >class entry. Later in the probe function I do
> >> >kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); to indicate a
> >> >monitor change.
> >>
> >> Don't use that function. It is only for the driver core. It will execute
> >> a usermode_helper which is not the way to do new stuff. Use the netlink
> >> events for that: If your application is some low-level stuff, listen
> >> directly to uevents:
> >>   http://www.kernel.org/pub/linux/utils/kernel/hotplug/uevent_listen.c
> >
> >What do I use instead of this to generate the netlink event?
> >kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT);
> 
> kobject_uevent()
> 
> >The user mode helper for monitor change needs to run as root. Do I use
> >the same /etc/hotplug.d directories for netlink?
> 
> No, uevents don't do anything by themselves, they are just sent from the
> kernel and something that listens to it, can do whatever is needed.
> You need your own listener for these events, or add that code to an
> existing system wide thing like HAL.

I'm not sure this is achieving what I need. There are two events

1) Hardware interrupt on monitor change
This event needs to cause a root priv executable to run
The executable may be specific to the device and it messes with the hardware.
This is not an event for system wide consumption
Code in this event converts the card specific data into a general form

2) A system wide event saying the the monitor has been changed. 
Runs after #1
This one fits into the netlink/hal/dbus model
A common data format is broadcast for all consumers

kobject_hotplug() did exactly what I needed for #1. In the netlink
model it looks like I have to have a daemon running listening for the
event. Most systems will never generate a monitor change interrupt
except at boot so I'd prefer not to keep a daemon running for this
event. Should I just switch #1 to directly use call_usermodehelper()?

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Greg KH]

On Fri, Feb 25, 2005 at 11:18:33AM -0500, Jon Smirl wrote:
> I working on adding hotplug monitor change detection code to some
> framebuffer drivers. I having trouble with event sequencing.
> 
> In my probe function I do a class_simple_device_add() to create the
> class entry. Later in the probe function I do
> kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); to indicate a
> monitor change.

Don't use KOBJ_MOUNT, use your own, new event type.  And when you do it,
a netlink event will also be generated at the same time (to answer your
later question.)

> I'm receiving the MOUNT event before the ADD one. How can I control the order?

You can't, but you can watch the sequence number to make sure you
process the events in the proper order.  udev does this.

> Even in cases where MOUNT comes after ADD udev has not built my device
> nodes yet. My MOUNT app needs to use the device node. This is my
> bigger problem.

Sit and spin, waiting for the device node to show up :)

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Greg KH]

On Fri, Feb 25, 2005 at 05:53:27PM +0100, Kay Sievers wrote:
> On Fri, 2005-02-25 at 11:18 -0500, Jon Smirl wrote:
> >I working on adding hotplug monitor change detection code to some
> >framebuffer drivers. I having trouble with event sequencing.
> >
> >In my probe function I do a class_simple_device_add() to create the
> >class entry. Later in the probe function I do
> >kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); to indicate a
> >monitor change.
> 
> Don't use that function. It is only for the driver core. It will execute
> a usermode_helper which is not the way to do new stuff. Use the netlink
> events for that: If your application is some low-level stuff, listen
> directly to uevents:
>   http://www.kernel.org/pub/linux/utils/kernel/hotplug/uevent_listen.c
> 
> or if it's desktop stuff, add support to HAL for it.

No, it's ok for him to call kobject_hotplug() for this type of event (we
explicitly said it was ok to do so at the last kernel summit).

He just needs to create a new type of kobject event, "mount" is not the
proper one here.  KOBJ_MODE_CHANGE perhaps?

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Kay Sievers]

On Fri, 2005-02-25 at 19:29 -0800, Greg KH wrote:
>On Fri, Feb 25, 2005 at 05:53:27PM +0100, Kay Sievers wrote:
>> On Fri, 2005-02-25 at 11:18 -0500, Jon Smirl wrote:
>> >I working on adding hotplug monitor change detection code to some
>> >framebuffer drivers. I having trouble with event sequencing.
>> >
>> >In my probe function I do a class_simple_device_add() to create the
>> >class entry. Later in the probe function I do
>> >kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); to indicate a
>> >monitor change.
>> 
>> Don't use that function. It is only for the driver core. It will execute
>> a usermode_helper which is not the way to do new stuff. Use the netlink
>> events for that: If your application is some low-level stuff, listen
>> directly to uevents:
>>   http://www.kernel.org/pub/linux/utils/kernel/hotplug/uevent_listen.c
>> 
>> or if it's desktop stuff, add support to HAL for it.
>
>No, it's ok for him to call kobject_hotplug() for this type of event (we
>explicitly said it was ok to do so at the last kernel summit).

So what about creating a class device for the monitor, which will be
created and removed?

Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Greg KH]

On Sat, Feb 26, 2005 at 04:43:23AM +0100, Kay Sievers wrote:
> On Fri, 2005-02-25 at 19:29 -0800, Greg KH wrote:
> >On Fri, Feb 25, 2005 at 05:53:27PM +0100, Kay Sievers wrote:
> >> On Fri, 2005-02-25 at 11:18 -0500, Jon Smirl wrote:
> >> >I working on adding hotplug monitor change detection code to some
> >> >framebuffer drivers. I having trouble with event sequencing.
> >> >
> >> >In my probe function I do a class_simple_device_add() to create the
> >> >class entry. Later in the probe function I do
> >> >kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); to indicate a
> >> >monitor change.
> >> 
> >> Don't use that function. It is only for the driver core. It will execute
> >> a usermode_helper which is not the way to do new stuff. Use the netlink
> >> events for that: If your application is some low-level stuff, listen
> >> directly to uevents:
> >>   http://www.kernel.org/pub/linux/utils/kernel/hotplug/uevent_listen.c
> >> 
> >> or if it's desktop stuff, add support to HAL for it.
> >
> >No, it's ok for him to call kobject_hotplug() for this type of event (we
> >explicitly said it was ok to do so at the last kernel summit).
> 
> So what about creating a class device for the monitor, which will be
> created and removed?

He already has a fb device, right?  That's all that is needed.  I don't
see what the problem is with calling kevent_hotplug() for a valid
kobject.  What's the big objection?

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Kay Sievers]

On Fri, 2005-02-25 at 19:58 -0800, Greg KH wrote:
>On Sat, Feb 26, 2005 at 04:43:23AM +0100, Kay Sievers wrote:
>> On Fri, 2005-02-25 at 19:29 -0800, Greg KH wrote:
>> >On Fri, Feb 25, 2005 at 05:53:27PM +0100, Kay Sievers wrote:
>> >> On Fri, 2005-02-25 at 11:18 -0500, Jon Smirl wrote:
>> >> >I working on adding hotplug monitor change detection code to some
>> >> >framebuffer drivers. I having trouble with event sequencing.
>> >> >
>> >> >In my probe function I do a class_simple_device_add() to create the
>> >> >class entry. Later in the probe function I do
>> >> >kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); to indicate a
>> >> >monitor change.
>> >> 
>> >> Don't use that function. It is only for the driver core. It will execute
>> >> a usermode_helper which is not the way to do new stuff. Use the netlink
>> >> events for that: If your application is some low-level stuff, listen
>> >> directly to uevents:
>> >>   http://www.kernel.org/pub/linux/utils/kernel/hotplug/uevent_listen.c
>> >> 
>> >> or if it's desktop stuff, add support to HAL for it.
>> >
>> >No, it's ok for him to call kobject_hotplug() for this type of event (we
>> >explicitly said it was ok to do so at the last kernel summit).
>> 
>> So what about creating a class device for the monitor, which will be
>> created and removed?
>
>He already has a fb device, right?  That's all that is needed.  I don't
>see what the problem is with calling kevent_hotplug() for a valid
>kobject.  What's the big objection?

Cause it may be nice to add and remove a monitor device instead of a two
stage event for the same device with "change" actions. No big
objection. :) I'm just asking, cause it sounds like a monitor hotplug
event.

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Greg KH]

On Sat, Feb 26, 2005 at 06:08:17AM +0100, Kay Sievers wrote:
> On Fri, 2005-02-25 at 19:58 -0800, Greg KH wrote:
> >On Sat, Feb 26, 2005 at 04:43:23AM +0100, Kay Sievers wrote:
> >> On Fri, 2005-02-25 at 19:29 -0800, Greg KH wrote:
> >> >On Fri, Feb 25, 2005 at 05:53:27PM +0100, Kay Sievers wrote:
> >> >> On Fri, 2005-02-25 at 11:18 -0500, Jon Smirl wrote:
> >> >> >I working on adding hotplug monitor change detection code to some
> >> >> >framebuffer drivers. I having trouble with event sequencing.
> >> >> >
> >> >> >In my probe function I do a class_simple_device_add() to create the
> >> >> >class entry. Later in the probe function I do
> >> >> >kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); to indicate a
> >> >> >monitor change.
> >> >> 
> >> >> Don't use that function. It is only for the driver core. It will execute
> >> >> a usermode_helper which is not the way to do new stuff. Use the netlink
> >> >> events for that: If your application is some low-level stuff, listen
> >> >> directly to uevents:
> >> >>   http://www.kernel.org/pub/linux/utils/kernel/hotplug/uevent_listen.c
> >> >> 
> >> >> or if it's desktop stuff, add support to HAL for it.
> >> >
> >> >No, it's ok for him to call kobject_hotplug() for this type of event (we
> >> >explicitly said it was ok to do so at the last kernel summit).
> >> 
> >> So what about creating a class device for the monitor, which will be
> >> created and removed?
> >
> >He already has a fb device, right?  That's all that is needed.  I don't
> >see what the problem is with calling kevent_hotplug() for a valid
> >kobject.  What's the big objection?
> 
> Cause it may be nice to add and remove a monitor device instead of a two
> stage event for the same device with "change" actions. No big
> objection. :) I'm just asking, cause it sounds like a monitor hotplug
> event.

Hm, I don't think the kernel knows about a "monitor", just a fb device.
Right Jon?

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Jon Smirl]

On Fri, 25 Feb 2005 21:35:37 -0800, Greg KH <greg@kroah.com> wrote:
> Hm, I don't think the kernel knows about a "monitor", just a fb device.
> Right Jon?

Correct.

Current changes are under way to make one fb device per head. I could
make a sysfs monitor entry but you would not want a class_device since
there is no major and /dev device for monitors.

Personally I would rather rework something like radeonfb into three
devices, the base card and two heads (monitors), but that's not the
way fbdev is going. The change would require rewriting 75 existing
video device drivers. Maybe in 2.7 if ten more fbdev developers show
up.

This situation is normally triggered by people with KVM switches which
can be used to change the monitor attached to the video card. There
have been numerous complaints filed against X.


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Kay Sievers]

On Sat, 2005-02-26 at 01:25 -0500, Jon Smirl wrote:
>On Fri, 25 Feb 2005 21:35:37 -0800, Greg KH <greg@kroah.com> wrote:
>> Hm, I don't think the kernel knows about a "monitor", just a fb device.
>> Right Jon?
>
>Correct.
>
>Current changes are under way to make one fb device per head. I could
>make a sysfs monitor entry but you would not want a class_device since
>there is no major and /dev device for monitors.

The reason I'm asking is that it's always nice if userspace can read the
current device state from sysfs at any time and not only at event time.

Stuff like HAL heavily depends on that as it needs to get the initial
state of all devices at startup to present this to applications. But if
there is any other way to get that without sysfs, it would work too,
sure.

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Kay Sievers]

On Fri, 2005-02-25 at 11:18 -0500, Jon Smirl wrote:
>I working on adding hotplug monitor change detection code to some
>framebuffer drivers. I having trouble with event sequencing.

Oh, back to the original question and sorry for all that noise. :)

>In my probe function I do a class_simple_device_add() to create the
>class entry. Later in the probe function I do
>kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); to indicate a
>monitor change.
>
>I'm receiving the MOUNT event before the ADD one. How can I control the order?
>
>Even in cases where MOUNT comes after ADD udev has not built my device
>nodes yet. My MOUNT app needs to use the device node. This is my
>bigger problem.

The event for the fb device needs to create a device node and therefore
takes longer than the mount event which seems to happen at the same
time. That's the reason for the unpredictable order, which can happen
anytime with "normal" hotplug.

But all events sent through the kobject_hotplug have kernel created
sequence numbers and udevd reorders the events to be executed in the
right order.
All events belonging to a device will be executed one after the other if
udevd recognizes a dependency, which is: the same devpath, a parent
device or a physical device behind it.

To solve all known kind of timing problems, we changed udev to be able
to take over the whole hotplug event and give the "normal" hotplug
scripts the same sane timing we need to have for udev to work properly.

udev versions later than 047 recognize if /proc/sys/kernel/hotplug is set
to /sbin/udevsend and then handle the hotplug scripts too.

> I'm using RH FC3 but this needs to work on all distributions when finished.

Fedora-Devel has already switched to "managed hotplug events" and the whole
system depends on udevd to handle hotplug.d/. Your should not see this
problem there.

Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Jon Smirl]

On Sat, 26 Feb 2005 14:11:08 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> Stuff like HAL heavily depends on that as it needs to get the initial
> state of all devices at startup to present this to applications. But if
> there is any other way to get that without sysfs, it would work too,
> sure.

I do have somewhat of a race issue. 

1) receive hardware interrupt of monitor change
2) empty the list of valid modes in sysfs
3) generate hotplug event to run userspace helper
4) userspace helper sets in new mode list
5) driver generates HAL event

X could have picked a mode from the modelist before #1
Then tried to set it between #1 and #4
In this case X will get an error about invalid mode
That should cause a popup that tells the user to try again
while that popup is up the HAL event occurs indicating a new mode list
is available
This needs to be sorted out so that the contents of the mode selection
dialog update

There need to be two events:
MODELIST_CHANGE
MODE_CHANGE

MODE_CHANGE occurs if you are in an xterm and set a new mode via the
command line. X needs to know in order to fix the display.

I was just using MOUNT temporarily.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Jon Smirl]

On Sat, 26 Feb 2005 15:00:24 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Fri, 2005-02-25 at 11:18 -0500, Jon Smirl wrote:
>>I'm receiving the MOUNT event before the ADD one. How can I control the order?

I just reworked things to only need sysfs during the monitor change
event so now I don't have to worry about /dev/xx not being there.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Kay Sievers]

On Sat, 2005-02-26 at 12:34 -0500, Jon Smirl wrote:
>On Sat, 26 Feb 2005 14:11:08 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> Stuff like HAL heavily depends on that as it needs to get the initial
>> state of all devices at startup to present this to applications. But if
>> there is any other way to get that without sysfs, it would work too,
>> sure.
>
>I do have somewhat of a race issue. 
>
>1) receive hardware interrupt of monitor change
>2) empty the list of valid modes in sysfs
>3) generate hotplug event to run userspace helper
>4) userspace helper sets in new mode list
>5) driver generates HAL event
>
>X could have picked a mode from the modelist before #1
>Then tried to set it between #1 and #4
>In this case X will get an error about invalid mode
>That should cause a popup that tells the user to try again
>while that popup is up the HAL event occurs indicating a new mode list
>is available
>This needs to be sorted out so that the contents of the mode selection
>dialog update

Yeah, this happens with other devices too and I don't see it as a big
problem as long as is fails and the caller get an error back.

>There need to be two events:
>MODELIST_CHANGE
>MODE_CHANGE
>
>MODE_CHANGE occurs if you are in an xterm and set a new mode via the
>command line. X needs to know in order to fix the display.

Are the list and the current state available as device attributes in
sysfs? So you may just send a KOBJ_CHANGE event for that specific
attributes with the kobject_uevent() which can have an attribute passed
down which is appended to the devpath of the device.

Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Jon Smirl]

On Sat, 26 Feb 2005 19:28:10 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> Are the list and the current state available as device attributes in
> sysfs? So you may just send a KOBJ_CHANGE event for that specific
> attributes with the kobject_uevent() which can have an attribute passed
> down which is appended to the devpath of the device.

Mode and modes are both sysfs variables so KOBJ_CHANGE should work to
send the events to hal. These are the public events that everyone
should know about.

That leaves my private monitor change interrupt event in
kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); It doesn't
make sense to remove/add the framebuffer device just because the
monitor attached changed. Remove/add would force X to close the
framebuffer device and lose all of the state loaded inside of it (font
cache, textures if DRM is running) .

What about adding a few defines for KOBJ_HELPER_1, KOBJ_HELPER_2,
KOBJ_HELPER_3, etc? Wouldn't this be better than making specific
defines for private helpers like my DDC decoder? KOBJ_HELPER would be
context specific on the class of the device.

I also want to modify request_firmware() to be more general. Secondary
video cards need to be posted before the sysfs class is created.
request_firmware() almost does what I need. It would be more useful if
I renamed it to request_initialization() then created two events:
KOBJ_FIRMWARE and KOBJ_POST. Alternatively I could pass FIRMWARE or
POST as an environment variable. The user space post program is the
same for all video cards.

Once we get this hashed out I'll post a summary to LKML for wider comment.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Kay Sievers]

On Sat, 2005-02-26 at 14:17 -0500, Jon Smirl wrote:
>On Sat, 26 Feb 2005 19:28:10 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> Are the list and the current state available as device attributes in
>> sysfs? So you may just send a KOBJ_CHANGE event for that specific
>> attributes with the kobject_uevent() which can have an attribute passed
>> down which is appended to the devpath of the device.
>
>Mode and modes are both sysfs variables so KOBJ_CHANGE should work to
>send the events to hal. These are the public events that everyone
>should know about.

That sounds good, yes.

>That leaves my private monitor change interrupt event in
>kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); It doesn't
>make sense to remove/add the framebuffer device just because the
>monitor attached changed. Remove/add would force X to close the
>framebuffer device and lose all of the state loaded inside of it (font
>cache, textures if DRM is running) .

For exactly that reason I was asking if it wouldn't be better to create
a child for the monitor, which can appear and disappear and can hold the
DDC data you get from the physical monitor.

>What about adding a few defines for KOBJ_HELPER_1, KOBJ_HELPER_2,
>KOBJ_HELPER_3, etc? Wouldn't this be better than making specific
>defines for private helpers like my DDC decoder? KOBJ_HELPER would be
>context specific on the class of the device.

Hmm, I'm not sure here. Can't you add the device specific stuff to the
environment and send out KOBJ_REQUEST_DATA or something? (See below.)

>I also want to modify request_firmware() to be more general. Secondary
>video cards need to be posted before the sysfs class is created.
>request_firmware() almost does what I need. It would be more useful if
>I renamed it to request_initialization() then created two events:
>KOBJ_FIRMWARE and KOBJ_POST. Alternatively I could pass FIRMWARE or
>POST as an environment variable. The user space post program is the
>same for all video cards.

I think the request_firmware() should be redesigned in a generic
request_user_data(kobj) call. This event would copy arbitrary data into
a sysfs file and something like KOBJ_REQUEST_DATA would do it.

The call should create a file inside of a existing device and the event
handler should copy the data into this file instead of creating a own
class device for the firmware as we do today.

Kay




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Jon Smirl]

On Sat, 26 Feb 2005 20:41:16 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> >That leaves my private monitor change interrupt event in
> >kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); It doesn't
> >make sense to remove/add the framebuffer device just because the
> >monitor attached changed. Remove/add would force X to close the
> >framebuffer device and lose all of the state loaded inside of it (font
> >cache, textures if DRM is running) .
> 
> For exactly that reason I was asking if it wouldn't be better to create
> a child for the monitor, which can appear and disappear and can hold the
> DDC data you get from the physical monitor.

I'm still thinking about this one. But you could use a parallel
argument on disks, and eliminate the MOUNT event. Maybe MOUNT should
be replaced with a child too.

> The call should create a file inside of a existing device and the event
> handler should copy the data into this file instead of creating a own
> class device for the firmware as we do today.

This part I definitely agree with.


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Jon Smirl]

On Sat, 26 Feb 2005 20:41:16 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> >That leaves my private monitor change interrupt event in
> >kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); It doesn't
> >make sense to remove/add the framebuffer device just because the
> >monitor attached changed. Remove/add would force X to close the
> >framebuffer device and lose all of the state loaded inside of it (font
> >cache, textures if DRM is running) .
> 
> For exactly that reason I was asking if it wouldn't be better to create
> a child for the monitor, which can appear and disappear and can hold the
> DDC data you get from the physical monitor.

I just spent half a day trying to get this to work. class_device can
not make child nodes (class/graphics/fb0/monitor) in it's current
form. It forces the node to appear in class/graphics/monitor.

I tried building the monitor entry directly off from kobjects but I
need all of the hotplug support from class_device and most of the
functions are declared static.

I also tried this:
	class_device = kmalloc(sizeof(*class_device), GFP_KERNEL);
	memset(class_device, 0, sizeof(*class_device));
	class_device->kobj.parent = &info->class_device->kobj;
	strncpy(class_device->class_id, "monitor", sizeof(class_device->class_id));
	ret = class_device_register(class_device);

But class_device_register will trap in class_device_add_attrs because
'class' is null. If I set class the node will appear in
class/graphics/monitor

I can try and fix up class_device but for this to work Greg is going
to need to change class_device to officially support child nodes.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Kay Sievers]

On Sun, 2005-02-27 at 23:53 -0500, Jon Smirl wrote:
>On Sat, 26 Feb 2005 20:41:16 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> >That leaves my private monitor change interrupt event in
>> >kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); It doesn't
>> >make sense to remove/add the framebuffer device just because the
>> >monitor attached changed. Remove/add would force X to close the
>> >framebuffer device and lose all of the state loaded inside of it (font
>> >cache, textures if DRM is running) .
>> 
>> For exactly that reason I was asking if it wouldn't be better to create
>> a child for the monitor, which can appear and disappear and can hold the
>> DDC data you get from the physical monitor.

>I tried building the monitor entry directly off from kobjects but I
>need all of the hotplug support from class_device and most of the
>functions are declared static.

It may work as a child of the physical device. Or something like:
  net/bridge/br_sysfs_if.c:br_sysfs_addif()

is doing it, may work.

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Jon Smirl]

On Mon, 28 Feb 2005 12:25:26 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> It may work as a child of the physical device. Or something like:
>   net/bridge/br_sysfs_if.c:br_sysfs_addif()

I can make this work with a small pactch to drivers/base/class.c
I need to modify class_device_add to not stomp the parent field if it
is passed in.

Greg, is this a reasonable way to fix this, or is a new API that
explicitly passes in the parent needed, or do you just hate the whole
idea in general?

=== class.c 1.57 vs edited ==--- 1.57/drivers/base/class.c   2004-12-21 19:29:34 -05:00
+++ edited/class.c      2005-02-28 14:03:46 -05:00
@@ -417,7 +417,7 @@

        /* first, register with generic layer. */
        kobject_set_name(&class_dev->kobj, "%s", class_dev->class_id);
-       if (parent)
+       if (parent && !class_dev->kobj.parent)
                class_dev->kobj.parent = &parent->subsys.kset.kobj;

        if ((error = kobject_add(&class_dev->kobj)))


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Greg KH]

On Sat, Feb 26, 2005 at 02:17:35PM -0500, Jon Smirl wrote:
> On Sat, 26 Feb 2005 19:28:10 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > Are the list and the current state available as device attributes in
> > sysfs? So you may just send a KOBJ_CHANGE event for that specific
> > attributes with the kobject_uevent() which can have an attribute passed
> > down which is appended to the devpath of the device.
> 
> Mode and modes are both sysfs variables so KOBJ_CHANGE should work to
> send the events to hal. These are the public events that everyone
> should know about.
> 
> That leaves my private monitor change interrupt event in
> kobject_hotplug(&info->class_device->kobj, KOBJ_MOUNT); It doesn't
> make sense to remove/add the framebuffer device just because the
> monitor attached changed. Remove/add would force X to close the
> framebuffer device and lose all of the state loaded inside of it (font
> cache, textures if DRM is running) .
> 
> What about adding a few defines for KOBJ_HELPER_1, KOBJ_HELPER_2,
> KOBJ_HELPER_3, etc? Wouldn't this be better than making specific
> defines for private helpers like my DDC decoder? KOBJ_HELPER would be
> context specific on the class of the device.

No, we want you to have to justify a new KOBJ value.  This ensures we
don't get a lot of undocumented usages that we have to support forever
without really knowing how they are being used.

I have no problem with adding KOBJ_MODE_CHANGE or some such event type
for this application, so don't think of it as something you will not be
able to get.

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Greg KH]

On Sun, Feb 27, 2005 at 11:53:12PM -0500, Jon Smirl wrote:
> 
> I can try and fix up class_device but for this to work Greg is going
> to need to change class_device to officially support child nodes.

It's on my todo list, after this lock rework logic is complete.  We'll
get there eventually, sorry it's not there yet.

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Greg KH]

On Mon, Feb 28, 2005 at 02:07:37PM -0500, Jon Smirl wrote:
> On Mon, 28 Feb 2005 12:25:26 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > It may work as a child of the physical device. Or something like:
> >   net/bridge/br_sysfs_if.c:br_sysfs_addif()
> 
> I can make this work with a small pactch to drivers/base/class.c
> I need to modify class_device_add to not stomp the parent field if it
> is passed in.
> 
> Greg, is this a reasonable way to fix this, or is a new API that
> explicitly passes in the parent needed, or do you just hate the whole
> idea in general?

I like the idea of your patch, but I think it breaks when we remove the
class_device device, right?  Or if we remove the parent class_device
first.

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Jon Smirl]

On Mon, 28 Feb 2005 11:56:43 -0800, Greg KH <greg@kroah.com> wrote:
> I like the idea of your patch, but I think it breaks when we remove the
> class_device device, right?  Or if we remove the parent class_device
> first.

Added code to inc the parent's ref count. 
BTW if parent is NULL the later call to
class_device_add_attrs(class_dev); is going to trap.

[jonsmirl@jonsmirl base]$ bk diffs -u
=== class.c 1.57 vs edited ==--- 1.57/drivers/base/class.c   2004-12-21 19:29:34 -05:00
+++ edited/class.c      2005-02-28 16:10:04 -05:00
@@ -417,8 +417,9 @@

        /* first, register with generic layer. */
        kobject_set_name(&class_dev->kobj, "%s", class_dev->class_id);
-       if (parent)
+       if (parent && !class_dev->kobj.parent)
                class_dev->kobj.parent = &parent->subsys.kset.kobj;
+       class_dev->kobj.parent = kobject_get(class_dev->kobj.parent);

        if ((error = kobject_add(&class_dev->kobj)))
                goto register_done;
@@ -467,6 +468,7 @@
        class_device_driver_unlink(class_dev);
        class_device_remove_attrs(class_dev);

+       kobject_put(class_dev->kobj.parent);
        kobject_del(&class_dev->kobj);

        if (parent)
[jonsmirl@jonsmirl base]$


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Greg KH]

On Mon, Feb 28, 2005 at 04:13:23PM -0500, Jon Smirl wrote:
> On Mon, 28 Feb 2005 11:56:43 -0800, Greg KH <greg@kroah.com> wrote:
> > I like the idea of your patch, but I think it breaks when we remove the
> > class_device device, right?  Or if we remove the parent class_device
> > first.
> 
> Added code to inc the parent's ref count. 
> BTW if parent is NULL the later call to
> class_device_add_attrs(class_dev); is going to trap.
> 
> [jonsmirl@jonsmirl base]$ bk diffs -u
> === class.c 1.57 vs edited ==> --- 1.57/drivers/base/class.c   2004-12-21 19:29:34 -05:00
> +++ edited/class.c      2005-02-28 16:10:04 -05:00
> @@ -417,8 +417,9 @@
> 
>         /* first, register with generic layer. */
>         kobject_set_name(&class_dev->kobj, "%s", class_dev->class_id);
> -       if (parent)
> +       if (parent && !class_dev->kobj.parent)
>                 class_dev->kobj.parent = &parent->subsys.kset.kobj;
> +       class_dev->kobj.parent = kobject_get(class_dev->kobj.parent);
> 
>         if ((error = kobject_add(&class_dev->kobj)))
>                 goto register_done;
> @@ -467,6 +468,7 @@
>         class_device_driver_unlink(class_dev);
>         class_device_remove_attrs(class_dev);
> 
> +       kobject_put(class_dev->kobj.parent);
>         kobject_del(&class_dev->kobj);
> 
>         if (parent)

And this works ok for you?  Hm, we don't really need to walk class
devices in "order" like we do for real devices, so this might be
acceptable.  But it just feels wrong, and I _know_ people will get this
wrong (everyone gets the class code wrong the first time they do it.)
We're trying to make this simpler, not more complex, with hidden "if you
set this pointer before you call a function, this magic happens..."

Anyway, let's do this properly, it's on the todo list, and will get done
in a few weeks.

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Jon Smirl]

On Tue, 1 Mar 2005 00:01:43 -0800, Greg KH <greg@kroah.com> wrote:
> Anyway, let's do this properly, it's on the todo list, and will get done
> in a few weeks.

I'll add notes in my fbdev patches that the class_device child code is
temporary and waiting on a real fix.

I'm changing the driver design to assume that I can do this. This
eliminates the need for a MODE_CHANGE event type. It makes more sense
looking at the sysfs entries too.

sys
  class
    graphics
      fb0(mode_list, mode)
        monitor(edid)
      fb1(mode_list, mode)
        monitor(edid)

If you unplug the monitor the monitor directory disappears and the
mode_list goes empty. The framebuffer is still there. Plug is back in
and the monitor directory is created and we get the hotplug event.
Hotplug event rebuilds the valid mode_list.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: event sequencing

[Greg KH]

On Tue, Mar 01, 2005 at 03:30:37AM -0500, Jon Smirl wrote:
> On Tue, 1 Mar 2005 00:01:43 -0800, Greg KH <greg@kroah.com> wrote:
> > Anyway, let's do this properly, it's on the todo list, and will get done
> > in a few weeks.
> 
> I'll add notes in my fbdev patches that the class_device child code is
> temporary and waiting on a real fix.

That's fine with me.

> I'm changing the driver design to assume that I can do this. This
> eliminates the need for a MODE_CHANGE event type. It makes more sense
> looking at the sysfs entries too.
> 
> sys
>   class
>     graphics
>       fb0(mode_list, mode)
>         monitor(edid)
>       fb1(mode_list, mode)
>         monitor(edid)
> 
> If you unplug the monitor the monitor directory disappears and the
> mode_list goes empty. The framebuffer is still there. Plug is back in
> and the monitor directory is created and we get the hotplug event.
> Hotplug event rebuilds the valid mode_list.

Oooh, that will be nice, I like it a lot.

Ok, that gives me an extra incentive to get this stuff working, let's
see if I can get some free time this week...

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel