Rather than go by the manufacturer, woudln't you be better off identifying
the BIOS ? (as that is what is primarily using the nvram).
> OTOH, some people are so keen to bloat the kernel that they'll put
> just about any kind of rubbish in it - or are you implying that the
> list of systems with various CMOS sizes is going to be small!!!
Agreed. Which is why I mentioned in an earlier mail that it doesn't
belong in kernel space. To reiterate: Set the amount of exported data
from /dev/nvram to the size of the biggest nvram that's known.
Let applications that use it do the sizing.
> > You want to run this code out of userspace ?
> Who said anything about using userspace?
Me probably.
> > Remember the address register is write-only and there is no way
> > to serialize access to it out of userspace (cli() will work
> > after iopl(3), but is not what you want on SMP systems).
> Since you're the one proposing a userspace solution, you'd better
> propose a way round that...if you see it as a problem, that is.
If the algorithm Riley presented isn't possible from userspace,
then either use the table approach, or (yeuch: a kernel space function
addressable from userspace, via a function call or whatever)
d.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/