On Thu, Apr 06, 2000 at 02:31:57PM -0400, Albert D. Cahalan wrote:
>
> BTW, the "allocate memory" idea limits you to a single int.
> We can have 32 k processes, but can only allocate 128 k of memory.
> I'd love to have an atomic ps, but I don't think it is practical.
I'm using vmalloc, so this is not that much of a problem. It'll become
a problem when I get to implementing mmap but I hear that's still
doable (like bttv.c or with a kiobuf extension).
> > Expansion can be done like this: the very first thing in the output is
> > an int that tells you how big the struct is. New fields are always
> > added at the end and old ps/top can just skip fields it doesn't know
> > about.
>
> An int would ruin 64-bit alignment. Something about this format seems
> ugly to me... it reminds me of the /dev/vcsa* devices. It is better
> to use an ioctl, minor number, etc.
Ioctl gets a lot of bad press on l-k, maybe I'm developping a mental
block :-). But I can see the above getting even uglier by the time I
fix the alignment and add the length of the data (for mmap), so
fine. Then I can use the same ioctl to retake the snapshot without
reopening the device.
Regards,
Borislav
-
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/
This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:17 EST