linux-kernel - Re: [Hdaps-devel] [PATCH 2.6.23-rc2] hwmon: HP Mobile Data Protection System 3D ACPI driver (resend)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070830164132.GA21023@khazad-dum.debian.net>
Date:	Thu, 30 Aug 2007 13:41:32 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Yan Burman <burman.yan@...il.com>
Cc:	Shem Multinymous <multinymous@...il.com>,
	hdaps-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
	Pavel Machek <pavel@....cz>
Subject: Re: [Hdaps-devel] [PATCH 2.6.23-rc2] hwmon: HP Mobile Data
	Protection System 3D ACPI driver (resend)

On Thu, 30 Aug 2007, Yan Burman wrote:
>>> You can generate events on input devices, but I am not sure that's the
>>> best way to go about it for this.  Things that block on read until an
>>> interrupt happens might work better.
>>
>> You can do the latter via another (4th) input device.
>>
> What's wrong with the stuff I did in mdps? a misc character device that
> acts like /dev/rtc. Why does it have to be input device oriented?

I am fine with a char device that acts like /dev/rtc, but if we are doing
something as heavyweight as a char device, I'd rather we go full generic
netlink and send the various events over it.  We'd have a netlink device
that sends everything over various "channels" and just one input device that
does joystick emulation, then.

Can we use a simple sysfs attribute that blocks the caller on write and
returns immediately on read? If it has to be more complicated than that, I'd
rather we go the netlink path. Any other ideas that are not a char device,
not a netlink socket, not an input device node, and not a sysfs attribute?

> I also looked at what you did in the patches as well as the modified 
> hdapsd. I'm doing the raw input device right now in the mdps, but I have a 
> suggestion.
>
> It seems to me that right now there are at least 3 drivers that provide the 
> same functionality - hdaps, ams and mdps. Why not create the input device
> that exports raw accelerometer data with a name that is generic - something 
> like accel/input or something along those lines. This way hdapsd could work
> with any driver that provides the functionality without being hdaps 
> specific.

THAT is the idea, IMO.  But the naming is userspace's problem (thorugh
udev), not ours :-)

Or do you mean the "hardware port" part of the input device? If so, yes, we
should try to make standard names for those as that makes it easier for
userspace.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/