/dev/nvram driver
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?
Signature · 4 lines
Tim Hockin Systems Software Engineer Sun Microsystems, Cobalt Server Appliances [email protected]
Quoted 2 lines · Tim Hockin
Who is maintaining the
/dev/nvramdriver? I have a couple things I want to suggest/ask.
I haven't seen any patches for ages to nvram, so I presume nobody.
Quoted 4 lines
What I really want to know is: should I bother making
nvram_open_cntSMP 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
Signature · 3 lines
Jeff Garzik | Andre the Giant has a posse. Building 1024 | MandrakeSoft |
Quoted 4 lines
Currently it tracks
O_EXCLonopen()and sets a flag, whereby no otheropen()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, shouldopen()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