bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: heimdal on GNU HURD


From: Marcus Brinkmann
Subject: Re: heimdal on GNU HURD
Date: Sat, 29 Sep 2001 12:50:59 +0200
User-agent: Mutt/1.3.22i

On Fri, Sep 28, 2001 at 05:15:46PM -0700, James Morrison wrote:
>   However, your 1st note is something I don't agree with.  For
> example MAXPATHLEN is defined on many systems, but is not the best way
> to find the limitations of the system because different filesystems
> could have different limits.  For example if a GNU/Linux system
> has an nfs filesystem mounted from a GNU/Hurd system or any system
> with a larger MAXPATHLEN, the program would break when retrieving
> a file off the nfs mount when it really shouldn't.  This is a 
> simple plee for the use of pathconf. 

Jeames is absolutely right here.  And if you use path_conf, you will notice
that it might return -1, as it does on the Hurd, indicating that there is no
limit on the filesystem denoted by the path.

>   A note on defined constants, I think FILENAME_MAX is too small on
> GNU/Hurd at only 1024.  I think something large, as implied by the
> documentation of glibc, like 65667 should be used.  

Sorry, there is a reason why it is 1024 (it's the limit imposed by the
remote procedure calls, IIRC).  We don't like it that way, but the current
calue expresses the current limitation correctly.
 
> --- "Jacques A. Vidrine" <n@nectar.com> wrote:
> > Hi,
> > 
> > Thanks for the report.  I do not think the answer is to add a new
> > API.
> > 
> > Almost  all  versions of  UNIX  specify  MAXHOSTNAMELEN (see 
> > [Stevens
> > UNPv1]).  The Hurd probably should, too.

I don't have a copy of Stevens right here, but last time I looked at it,
Stevens was very careful with dealing with systems which don't define
PATH_MAX (and if I recall correctly, those that do not define
MAXHOSTNAMELEN, but I am not sure on that).
 
> > Regardless,  the next  version of  POSIX specifies  HOST_NAME_MAX. 
> > We  should probably  be using  HOST_NAME_MAX instead of  MAXHOSTNAMELEN
> > in the Heimdal sources, or at least do something such as
> > 
> >  #if !defined(MAXHOSTNAMELEN) && defined(HOST_NAME_MAX)
> >  #define MAXHOSTNAMELEN HOST_NAME_MAX
> >  #endif
> > 
> > IMHO a system that defines neither MAXHOSTNAMELEN nor HOST_NAME_MAX
> > is broken [1].

[cutting signature]

> > [1]  I'm ignoring  the  fact that  HOST_NAME_MAX is  one  of the 
> > many `possibly  indeterminate  run-time   invariant  values'.   Any 
> > system designer  that requires  use  of sysconf()  for  such basic 
> > constants should be drawn-and-quartered :-)

We not only require you to use sysconf, we also let sysconf return -1, to
indicate that there is no fixed limit.  There is a good reason we do so.
First, there really is no limit, so saying that there is a fixed limit
although there really is none is simply wrong.

So why is there no limit?  Because we do not like to impose arbitrary
limits on the users.  Arbitrary limits always turn out to be too small at
some time, and they are a hard limit for scaleability.

There is a deeper reason why on the Hurd defining a limit nevertheless would
be wrong.  The Hurd is a user extensible system.  This means that any
component of the Hurd system can be ignored/overwritten/replaced by the
*users* of the system without restriction and without compromising security. 
But to make it easier for users to be able to continue the usage of the
default libraries and system components, we write those components in the
most flexible way, setting as little constraints as possible.  One such
constrain is the length on hostnames.

Of course, people who have excessive needs can always patch and compile
their own copy of the applications and run them.  However, we would be happy
to have the flexibility in the official versions of the software already.
We would like to say that the Hurd has no limit on the length of the
hostnames and the applications we compile for it don't impose one as well,
rather than saying that we don't have any limits, but heimdal imposes its
own limit constraining the user.

We have already fixed a lot of such ignorant applications, and usually the
authors and maintainers are happy to accept the patches.  So many programs
already support arbitrarty long hostnames on the Hurd.

However, as you are already aware of that heimdal is not a POSIX compliant
application while the Hurd is a POSIX compliant operating system, and you
prefer us to be drawn-and-quartered rather than fixing heimdal, I am not sure
what I can say to convince you otherwise, beside trying to explain to you
why we don't define an arbitrary limit.  I hope you agree after the above
explanation that there is really a value in not defining a limit and fixing
the applications that can't deal with the lack of it.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]