Borislav Deianov writes:
> On Wed, Apr 05, 2000 at 10:46:05PM -0400, Albert D. Cahalan wrote:
> I'm thinking of a fixed-sized struct per process and leaving 128k of
> space in each is not an option... I guess I can put something like 64
> bytes for command lines, better than nothing. Environment has that
> problem too, maybe skip that entirely, just the start is not very
> useful there.
How about 256 bytes for the command line? That is enough for a
fairly wide screen.
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 suggest that _everything_ be 64-bit for easy alignment and
>> expansion, especially considering ia64 with 32-bit apps.
>
> 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.
> I'm a bit reluctant to make everything 64-bit since that essentially
> doubles the size of the output on 32-bit archs. On the other hand
> there aren't many other choices if 32-bit support on 64-bit archs is
> needed. I suppose I can leave the int fields at 32-bit since int is 32
> bits on all current 64-bit archs, but that doesn't help too much -
> most of the fields are longs.
Don't use int. Often, data type sizes change. Just make everything
64-bit right now. This satisfies alignment requirements everywhere,
and it makes the need for expansion very unlikely.
(even with 16-bit values you can't allocate enough memory, so there
isn't any point in trying to squeeze the data to fit)
> So which is more important - 32-bit support on 64-bit or the size of
> the output on 32-bit native?
Output size is a minor issue compared to the long-term maintenance
issues associated with odd-sized structs. Just use a big array, to
ensure that future hackers will not be tempted to screw up the
alignment and expansion room with 32-bit types.
-
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