Messages in this thread | | | From | "Jones D (ISaCS)" <> | Subject | RE: PATCH: /dev/nvram cleanups. | Date | Thu, 29 Jul 1999 16:59:05 +0100 |
| |
> >>> Assuming that the algorithm you presented works on all the > >>> different sizes (which I think it will), that's a much more > >>> elegant solution than the lookup-table idea I presented, as > >>> it's zero maintainance. > > ahem. all new systems are going to have 128 byte NVRAMs anyway, > > so you could basically keep a list of systems that have 64 bytes > > only. > When composing that list, start by listing the entire CURRENT Packard > Bell range. Certainly all the models I've checked have 64 byte NVRAM > chips on them.
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/
| |