Re: cvs commit: src/sys/kern imgact_elf.c init_main.c kern_checkpoint.c kern_descrip.c kern_event.c sys_generic.c sys_pipe.c uipc_syscalls.c uipc_usrreq.c vfs_aio.c vfs_syscalls.c src/sys/sys filedesc.h src/sys/dev/misc/streams streams.c ...

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Wed, Jun 22, 2005 at 05:35:55PM +0100, Hiten Pandya wrote:
> Joerg Sonnenberger wrote:
> >On Wed, Jun 22, 2005 at 01:13:01PM +0200, Simon 'corecode' Schubert wrote:
> >
> >>Lately Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxxxxx> said:
> >>
> >>> Log:
> >>> File descriptor cleanup stage 2, remove the separate arrays for file
> >>> pointers, fileflags, and allocation counts and replace the mess with a
> >>> single structural array.  Also revamp the code that checks whether the
> >>> file descriptor array is built-in or allocated.
> >>
> >>can anybody enlighten me why this was done in the first place?
> >>this way it's much clearer anyways
> >
> >
> >But it is also slower because the amount of data which has to be copied 
> >when
> >the array is extended is now doubled. (pointer vs. struct fdnode)
> >
> >Joerg
> 
> 	Can't we not just make them all allocated?  I am assuming here that
> 	allocator descriptor arrays is "pointer" and the other is "fdnode",
> 	according to your interpretation, right?

I meant exactly what I wrote. We have to increase the size of the descriptor
table on demand, because a process might want e.g. descriptor 4096, but most
don't. Before, we stored a simple array of pointers, now it is an array of
struct fdnode's. The latter is twice the size, read the new code is a bit
slower when extending the array.

Joerg