[TUHS] Etymology of the open file table?

[crossd@gmail.com (Dan Cross)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]

Thanks, all. I kind of figured it was something like that....

On Tue, Mar 22, 2016 at 12:11 AM, Warner Losh <imp at bsdimp.com> wrote:

>
> > On Mar 21, 2016, at 10:00 PM, John Cowan <cowan at mercury.ccil.org> wrote:
> >
> > Dan Cross scripsit:
> >
> >> Those file structures are collected into a single, global table. The
> >> question is why this latter table? One could rather imagine an
> >> implementation where open() allocates (e.g., via malloc()) a new 'struct
> >> file' that contains as a structure field an 'int refcnt' that is
> >> incremented when a descriptor is dup()'d or as a side-effect of a
> fork(),
> >> and is decremented as a result of a close(); when 'refcnt' drops to
> zero,
> >> the structure could be freed with e.g. 'mfree'. What is the benefit of
> >> 'struct file file[];'?
> >
> > Sure you could, but it would be more complex, slower, and less robust.
> > "When in doubt, use brute force."  --ken
>
> And hard-coded limited, like the filesystem table, were all over the
> place in early OSes, mostly to cope with memory sharing on tiny
> RAM systems where it was better to just statically allocate things
> at compile time. This made the code simpler (and smaller) which
> made it both faster and allowed one to pack more functionality into
> the system. It was rare that you’d have so much memory you could
> take advantage of dynamic allocation. If you used all your file descriptors
> that were statically compiled into the kernel, chances are you wouldn’t
> have the address space to hold enough RAM to source and sink
> data to the files in question, nor deal with the connections between
> the file stable and the file system.
>
> Dynamic allocation, and moving away from static limits, only came
> about later, as memory sizes grew. It was this dynamic that made
> Ken’s advice such a win in the hardware of the day.
>
> Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160323/bcca29bb/attachment.html>