RE: On PATH_MAX

[Christopher Nelson]

> At Thu, 3 Nov 2005 11:21:17 -0700,
> "Christopher Nelson" <address@hidden> wrote:
> > Sure, but in practice how does this work?
> 
> In practice it works by first defining what your system looks 
> like, and then finding out what the constraints are.
> 
> The problems you describe stem from the fact that you have a 
> service that is used by multiple users concurrently, and 
> which expends some of its own resources in handling those messages.

Actually, I didn't mean that at all.  Say thread A allocates 4gb of
memory.  Say it then shares that memory with thread B.  Thread B cannot
do any meaningful work on that memory until it is mapped into it's
address space.  Thread B *must* use some of it's own resources (if you
consider space in your address space a resource) in order to do any
useful work on that information.  If thread B were to completely migrate
over to thread A's address space, how do you still maintain protection
boundaries?  How do you keep thread A from seeing any private or
privileged information that thread B might need in order to do it's job?
In order for thread A to remain confined, thread B must stay in it's own
address space.
 
> Under this constraints, you are already violating a number of 
> good principles.  But let's say that you figure out this is 
> ok in this circumstance.  Then the least you must do is to 
> ensure that all requests the service processes have a fixed 
> upper bound, preferably a really, really small one.
> 
> > > To say that the one or the other is stupid is just plain wrong.
> > > 
> > > Sometimes you should support dynamic reallocation.  Sometimes you 
> > > should have a fixed buffer and truncate.  You should not 
> limit your 
> > > toolset because of some half-cooked and
> > > (generally) _wrong_ programming dogmas.
> > 
> > I think it is wrong to have an arbitrary global limit, but I don't 
> > think that an application imposing an arbitrary 
> *reasonable* limit is 
> > wrong.  Because we *can* do something is not a good argument for 
> > actually doing that something.
> 
> If all you are saying that a system-wide limit is wrong, then think
> again: A system-wide limit is impossible to enforce.  It is 
> totally possible for you to set up your own filesystem 
> server, expending your own resources, in which arbitrary long 
> filenames are mapped transparently to the short "system-wide" 
> limit.  Nothing can stop you from doing so.  So the whole 
> notion of "global limit" is complete and utter non-sense.
> 
> However, _if_ there is a shared service in your system, then 
> for all I know the only sane implementations possible will be 
> one that imposes strict limits on the argument sizes it supports.
> 
> You want to use another party's resources, you play by their rules.
 
Lol. I'm not sure exactly what you're saying, but I *think* that I agree
with you. :-D  I don't so much mean that the kernel should impose it's
own idea about how much it's going to transfer, but rather that it
provide a mechanism which allows the receiver to say how much it wants
to receive.  The receiver should not be *forced* to accept what it is
given.

-={C}=-