/dev/nvram driver

/dev/nvram driver

[Tim Hockin]

Who is maintaining the /dev/nvram driver?  I have a couple things I want to
suggest/ask.  

Currently it tracks O_EXCL on open() and sets a flag, whereby no other
open() calls can succeed.  Is this functionality really needed?  Perhaps it
should just be a reader/writer model : n readers or 1 writer.  In that
case, should open() block on a writer, or return -EBUSY?

nvram_release() calls lock_kernel() - any particular reason?

various other bits (nvram_open_cnt, for example) are not SMP safe.  I'm
making sure it is safe now.

What I really want to know is: should I bother making nvram_open_cnt SMP
safe, or should it just go away all together.  I vote for the latter
option, unless something depends on this behavior (in which case, other
fixes are needed, because it is broken :).

comments?


-- 
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
thockin@sun.com

Re: /dev/nvram driver

[Jeff Garzik]

Tim Hockin wrote:
> Who is maintaining the /dev/nvram driver?  I have a couple things I want to
> suggest/ask.

I haven't seen any patches for ages to nvram, so I presume nobody.


> What I really want to know is: should I bother making nvram_open_cnt SMP
> safe, or should it just go away all together.  I vote for the latter
> option, unless something depends on this behavior (in which case, other
> fixes are needed, because it is broken :).

Once you figure out what the best behavior is (which I'm not sure of,
myself), I would suggest using a semaphore in the open and release
methods.

	Jeff


-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

Re: /dev/nvram driver

[Alan Cox]

> Currently it tracks O_EXCL on open() and sets a flag, whereby no other
> open() calls can succeed.  Is this functionality really needed?  Perhaps it
> should just be a reader/writer model : n readers or 1 writer.  In that
> case, should open() block on a writer, or return -EBUSY?

Several tools expect that mode of behaviour so that they can atomically
recompute the checksum when writing low bytes of the CMOS