linux-kernel - Re: sysfs and power management

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20101029195039.GA26401@suse.de>
Date:	Fri, 29 Oct 2010 12:50:39 -0700
From:	Greg KH <gregkh@...e.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	samu.p.onkalo@...ia.com, alan@...ux.intel.com,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: sysfs and power management

On Wed, Oct 27, 2010 at 03:28:09PM +0100, Alan Cox wrote:
> > Do you mean per device hook and each sysfs open / close uses 
> > per device ref-counting.
> 
> Or you can do it by having an optional per device hook which is passed
> the sysfs node for each open/close and leave the rest up to the driver.
> If it needs to do clever stuff it can.

I really don't want to add open/close to the sysfs file model for the
driver core.

What is the specific problem with not doing any sensor work until
userspace asks for the data?  Then do the read from the hardware and go
back to sleep.  That's probably the best way to do this, as userspace
isn't going to open the sysfs file and not close it instantly anyway
after it has read the data (seeking on a sysfs file isn't really
recommended, even if it sometimes seems to work.)

thanks,

greg k-h
--
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/