Dear Mr. Torokhov, Mr. Benjamin,
Greetings!

I sent a mail on January 25th, but still waiting for the reply.
Therefore, sending it again.
I hope to hear soon ~


On Tue, Jan 21, 2014 at 3:19 AM, Dmitry Torokhov
[off-list ref] wrote:

Hi Aniroop,

On Tue, Jan 21, 2014 at 01:34:07AM +0530, Aniroop Mathur wrote:

quoted

Hello Mr Tissoires
Greetings !!

On Jan 20, 2014 11:54 PM, "Benjamin Tissoires" [off-list ref]
wrote:

quoted

Hi Aniroop,

[sorry for top posting, but I really don't know where to put this

regarding your answers].

quoted

No problem at all.
In fact I am quite happy to hear from
Linux community again
Its my pleasure.

quoted

I _think_ I get one of the reasons you don't understand Dmitry, and why

Dmitry does not understand you. From the different mails, I would say that
you are referring to an Android platform.

quoted

If it's not the case, then sorry for the noise.

No I am not specifically referring to
Android platform
But yes, I am from android background
and through android only I came up with
this idea.

quoted

So, the last time I checked with android, this system does _not_ have an

udev user-space daemon, which means that what you seem to be doing is
parsing manually the sysfs tree to retrieve the inputs and their properties.

quoted

This, IMO, is a very bad idea. Parsing the entire sysfs tree is indeed

costly and you will have to build everything by hand.

quoted

No, Android also have a daemon but it is not udev daemon. There is a
separate daemon in android different from generic
udev daemon. It is different but basic is
still same.
Just like udev daemon, android daemon
also receives uevents from kernel
and creates devfs nodes for us,
that is /Dev/input/event1/2/3... based
on uevent env variables.
Android daemon is different from generic
daemon in a sense it does not see any file
like udev rules before creating nodes. Instead it directly create nodes as
per uevent env variables in the structure.
So without opening any extra udev rule
file, it create nodes.
So I understand it has also a limitation that it only has to be dependent
only on default uevents and cannot read any sysfs attribute to identify the
device if default uevents are not sufficient.

Why can it not?

It cannot because currently in android code, it does not read any
sysfs attribute.
It only reads default kernel uevents. I think functionality may be added to read
sysfs attribute also but this functionality is currently not added in
android code.
I think it is not added because in embedded system mostly there are only single
and unique devices and this manipulation might add extra time during android
initialization.

quoted

But the problem I am referring  is for both in case of generic kernel and
android kernel.

So far I really do not see it as generic kernel problem since we do have
existing infrastructure in userspace that is quite efficient.

The existing way is also there but there is always a scope of improvement.
Tell me which is more efficient ?
1. existing method in which udev opens and read udev files for setting name
or
2. Directly set name without doing extra calculations

Its correct existing method will also do the same task but why not to use
more efficient way.
I just want to improve efficiency.

quoted

quoted

On regular distros, we use udev. This daemon builds its device database

from the events generated by the kernels directly (the uevents). Once the
events are emitted, we never (except for some user-space drivers) use them
in the kernel drivers (at least, I never saw that).

quoted

So if you want to create symlinks, then indeed, you just add 2 or 3 rules

in /etc/udev/rules.d, and then the user space (and the system integrator)
can see the different devices with the "correct" symlink.

quoted

However, the kernel developer will never see them (and especially in the

->probe callback). However, the user-space tools which receives the udev
events (emitted from udev, not the kernel this time) can easily retrieve
many information from the event. Just run "udevadm info --export-db" on a
regular Linux, and you will see that the device which presents the event
node (/dev/input/eventX) has all the requirements to identify itself (VID,
PID, path, etc...)

quoted

Yes udev gives so many uevents but as I checked through logs specifically
in case of /Dev/input/event1/2/3/4....it does not give sufficient uevents
to identify the device.
As I found in logs it gives only 7 env variable like action, subsystem, Dev
name, Dev path, major, minor and seq number.
It does not give vendor Id or pid.
Now with these uevent we cannot identify the input device whether its
accelerometer or touchscreen. Can we ??

While information sent in uevent emitted for creation of event device
might not be enough to identify and classify input device you can:

1. Capture udevent sent a few moments earlier for the input device
   itself, or

2. Read /sys/class/$DEVNAME/device/uevent to retrieve input device's
uevent data:

[dtor@dtor-d630 work]$ cat /sys/class/input/event6/uevent
MAJOR=13
MINOR=70
DEVNAME=input/event6
[dtor@dtor-d630 work]$ cat /sys/class/input/event6/device/uevent
PRODUCT=11/2/8/300
NAME="AlpsPS/2 ALPS DualPoint TouchPad"
PHYS="isa0060/serio1/input0"
PROP=8
EV=b
KEY=e420 70000 0 0 0 0
ABS=260800001000003
MODALIAS=input:b0011v0002p0008e0300-e0,1,3,k110,111,112,145,14A,14D,14E,14F,ra0,1,18,2F,35,36,39,mlsfw
[dtor@dtor-d630 work]$

That should give you plenty data to work with. Yes, the 2nd option
involves additional filesystem operations, but this is sysfs (so you are
not hitting real media) and you only need a few (open, read, and close)
per device.

Yes this method can surely solve the task , but not the purpose.
My query is why not to use more efficient way when we can ?
( Already discussed this way is backward compatible and is optional to use)



Apart from above, Could you please tell me the role/use of init_name variable,
which is defined in "struct device" ?
(I think, it is also used to set name of device node)

Thanks,
Aniroop Mathur

Thanks.

--
Dmitry