Re: /dev/nvram driver
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/nvram driver
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 | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/nvram driver
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 | - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/nvram driver
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
