lkml.org 
[lkml]   [1999]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: PATCH: /dev/nvram cleanups.
Date

> >>> 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.042 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site