Problem:- Cannot open /dev/mem: too many open files
I was working on some (S)VGA code earlier this evening and have come across
a problem.... Linux thinks I have too many open files but I can't see how it
has arrived at this conclusion.
My code opens /dev/mem, mmap's it twice (text and graphics memory), does some
fiddling about and exits where and when expected. It doesn't close /dev/mem
or munmap ('cos a. unix should clear everything up shouldn't it? and b. I
forgot :-(). All this is done as root because of the permissions involved.
To cut a long story short, I played about with it, left it for a bit (machine
switched off), came back to it, played a bit more and then a call to open
suddenly started failing with the error message "too many open files". I have
tried rebooting, closing fd's 3 to getdtablesize() (19 in this case) - all to
no avail. So.....
What's up and how do I fix it? Everything I have tried has failed and I'm
kinda stumped by this one. Surely a file descriptor to an open file is
invalidated by a reboot.... is it something to do with the fact that I am
doing it all as root?
System details: 0.96b (patchlevel 2 I think) from tsx-11. Identifies itself
as 0.96a-41 Jul 6 1992 19:51:53 at bootup. Is this the true
identity? If so then there's been some mislabelling somewhere.
386-33 with 8Mb RAM, AMI BIOS, single Conner IDE hard drive.
Ta in advance,
p.s. Thanks to all who replied to my query about "device busy" as an error
message from rmdir. As most of the many replies explained, this error
can occur when a rmdir on one virtual console attempts to remove a
directory in use by another virtual console. This would certainly explain
my earlier findings but does not explain why a full reboot and an attempt
to rmdir with only one virtual console in use failed. I have managed to
remove the directory now so one more chalked up to experience!
p.p.s. Something just occurred to me (on a completely unrelated note). Many
people using linux only recompile the kernel to change the keyboard
or the rootdevice. How about a program to do this to the bootimage
without the need to recompile. The root device bit is easy... offsets
508 & 509. The keyboard is a bit trickier..... basically, it all works
around a function lookup table.... could this be edited post compile?
I seem to remember (from when I looked at it many moons ago) that it is
a fixed size table.... could it be set by an external program? Some
sort of marker for it would have to be set in the bootimage so that
a ?string? search could find the table and change its contents. Is