![]() | |||||||||||||||
Messages in this thread |
> -- This information is, in the very near future, _not_ going to be > static anymore. There will be systems that update the information in > dynamically during SMIs. That's fine - /dev/mem can handle that too. An user will have to poll for changes anyways, so having it it /proc does not have any advantages. I would see the sense if there was an interrupt to notify the the system of changes, but there isn't ;-) > > -- SMBIOS consists of two things, the table entry point and the table > itself. The table entry point is always in 0xF0000 - 0xFFFFF. > Traditionally, the actual table has been here as well. BIOS is running > out of space here and future systems are moving this information to high > memory. /dev/mem will not allow access to memory above top of system > RAM. mmap /dev/mem of high memory should work. Did you try it? For read/write it would be fairly easy to add, just needs a kmap. > -- Red Hat has a /dev/mem patch in their tree that restricts access to > RAM above 1MB. That's their breakage. Clearly it is a useless change anyways because you can easily circumvent it by just accessing any bus master hardware in the system. > This procfs/sysfs driver allows access to smbios information by > non-root, non CAP_SYS_RAWIO users. I've had several occasions where I > have been bitten by having to be root to read smbios when I did not need > root for anything else. That is what suid root was invented for. It is a fairly nifty mechanism, did you ever try it? I know that some sysadmins try to get away from it, but that is clearly misguided because it is not any more dangerous than adding more kernel code. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||||
| Last update: 2005-03-22 13:02 [from the cache] ©2003-2008 | |||||||||||||||