On Wed, 2006-12-13 at 00:26 +0100, Stefan Schmidt wrote:
> On Tue, 2006-12-12 at 15:00, Kristen Carlson Accardi wrote:
> >
> > I did have different dock/undock events a few months ago - but
> > after some discussion we scrapped them because Kay wants to avoid driver
> > specific events. The "change" event is the only thing that makes sense,
> > given the set of uevents available right now, and userspace should be
> > able to handle checking a file to get driver specific details (i.e. dock
> > and undock status). If you have a specific reason why this won't work,
> > let me know.
>
> It's fine with me. I just find two different events more handy.
> Checking the file after the event in userspace should not be aproblem.
The thing is that we try to avoid driver-core "features" that are
specific to a single subsystem or driver.
You can easily add additional environment variables today, while sending
a "change"-event with kobject_uevent_env(), like
ACPI_DOCK={lock,unlock,insert,remove,...}. Just pass any driver-specific
string you like along with the event, and it will be available just like
the "action" string.
This should fit all requirements, without the need to introduce all
sorts of new generic action-strings, that can almost never be changed
later for compatibility reasons. That way, if "drivers" later find out,
that they need to send different actions/flags, they can just add as
many new strings as they like on top of the event. :)
Thanks,
Kay
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
