Date: Thu, 21 Dec 1995 18:57:28 +0000 () From: Julian Elischer <julian@jhome.DIALix.COM> To: wollman@lcs.mit.edu (Garrett A. Wollman) Cc: wollman@lcs.mit.edu, phk@critter.tfs.com, current@freebsd.org Subject: Re: MOUNT_* constants Message-ID: <199512211857.SAA14092@jhome.DIALix.COM> In-Reply-To: <9512211843.AA27199@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Dec 21, 95 01:43:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > <<On Thu, 21 Dec 1995 18:27:36 +0000 (), Julian Elischer <julian@jhome.DIALix.COM> said: > > > The other thing I want to make dynamic is > > AF_INET and related constants... > > I see no reason to not have a pointer to a string "inet" > > for compatibility we can make pointers < 32 be treated as the old > > constant, but I hope to redefine AF_INET as "inet" > > some time this millenium :) > > Actually, there are a number of very strong reasons why you need to > keep these constants relatively small, short, easy to compare, and > valid arguments to a switch statement. The same is true of the > filesystem indexes; what I have come close to getting rid of is /not/ > the need for the constants themselves (which I believe will continue > to exist), but rather, the static mapping from name to number implied > in the MOUNT_* constants in <sys/mount.h>. There is the problem however of adding new protocols.. you need to add new constants in to socket.h which is a ROYAL PAIN in the neck. at TFS I have two protocols I add and I know there are other people who have proprietary protocols they add. Within the kernel, sure use an offsett if you want.. A compare of protocol names won't be much slower when looking for a protocols table however.. most string comparisons fail in the first 2 characters anyway.. this is not to be confused with the ETHERTYPE_INET type of constant that might be done at every packet.. I tend to have my AF_TFS value defined in a separate .h file from socket.h anyhow, so I don't have to modify that file.. > This is reasonable to do > because mount and statfs requests are relatively infrequent. Calls to > the socket functions, and the manipulation that is done internally of > these numbers by the socket code, are so frequent that it does not > make sense to do so. (We can't afford to take a speed hit in the > networking code, it's too slow as it is!) once you have openned a socket, then within the kernel, you can use some integer as an identifier, but I think the user interface should be more dynamic.. I think I got the idea from Mike Karels But I'm not sure.. > > -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512211857.SAA14092>