Re: [GIT PULL] Ambient Light Sensors subsystem
From: Jean Delvare
Date: Wed Mar 03 2010 - 06:02:57 EST
On Wed, 3 Mar 2010 02:29:09 -0800, Dima Zavin wrote:
> Thanks for the prompt reply.
> >> I definitely see the need for what you guys are trying to accomplish.
> >> For example, currently, we use an input device for reporting events,
> >> and a separate misc device node for control
> >> (enable/disable/configure). It's definitely suboptimal, but there
> >> currently isn't anything there would let us do things cleanly.
> >> What I would love to see is a more generic sensors framework that
> >> handles different kinds of sensor devices, and different data
> >> acquisition schemes (sampled vs. change notifications).
> >> I would love to work with you to design something more generic.
> > This can happen later, I see no reason to block the creation of the ALS
> > subsystem. Having a common framework for all ambient light sensor
> > drivers will already be a step forward compared to the current
> Following the logic of putting the ALS subsystem under drivers/als, we
> would then put the proximity subsystem under drivers/proximity, and
> then an accelerometer subsystem under drivers/accelerometer, etc. Each
> with their own implementation of very similar set of interfaces. Is
> that what you envision? I just figured that instead of creating
> one-off interfaces for some subset of environmental sensors such as
> als, we can add a sensors subsystem of which als is just an instance.
We need ALS support yesterday, so it can't build on top of a more
generic framework that doesn't exist today. If you want to design such
a generic framework, feel free, go ahead, and when it's ready, merge
everything you want in it. But we will not wait for you.
> > situation. If improvements are needed on top of this, this can happen
> > later.
> I'm just concerned that instead of solving the actual problem, you are
> adding what is essentially a temporary solution.
This is certainly true. But you have to realize that _all_ the kernel
code is a temporary solution. We change over 2000 lines of code every
day on average.
> This will only make
> it harder to solve the real issue by introducing new interfaces which
> will need to be obsoleted unless they are designed with care. What you
> are proposing already needs improvements since there are plenty of
> drivers floating out there from many OEMs/vendors that are not ALSs,
> but essentially need a similar interface (e.g. proximity sensor).
I don't care at all. I want ALS support, and I want it now. If you or
others want something else, go work on it. And if several subsystems
should share something, it can happen later. The point is, you won't
know what they need to share exactly until they are all already there
each with a decent set of drivers. So there is no real benefit in
designing the big thing first, because you'd have to adjust it later
> Furthermore, are there more patches coming for this subsystem? Based
> on the above tree, it just seems to be a class device (without any
> standard attributes) and a register/unregister function. It doesn't
> seem to actually be doing anything. Registering with the als subsystem
> at the moment buys the driver nothing. So, in its current state, I'm
> not sure I see what this new common framework actually provides us,
> and thus I'm not sure that it's actually a step forward.
There are two major benefits:
1* The set of available ALS drivers become visible: just look into
drivers/als and you get most of them, search for callers of the
registration function and you get them all. This will avoid redundant
code development, and will make adding new drivers easier.
2* All ALS devices will be reachable at the same location in sysfs.
There is no way user-space can consume whatever the drivers provide
without this common entry point. And we need user-space consumers,
otherwise we just don't know what the real needs are.
> The drivers
> are still responsible to provide all their own non-standard,
> incompatible sysfs interfaces for exporting the sensor values.
Apparently you did not read the patches all that carefully. One of them
creates a documentation file describing the standard sysfs files for ALS
drivers. All ALS driver must comply with it, so they are neither
non-standard nor incompatible. Note that the sysfs files are defined as
a "testing ABI", because we are well aware that it might change in a
near feature. We will move it to "stable ABI" when ready.
> there are other patches for the als subsys that are then used by the
> two drivers that got moved into drivers/als, I'd love to take a look
> at them.
Not that I am aware of. But again, it doesn't mean this won't happen
later, if the need arises. How do you expect us to know what code
should be common as long as we don't have a central place to store all
drivers and a common interface to their devices?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/