Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 07 Feb 2001 10:44:24 -0800
From:      Julian Elischer <julian@elischer.org>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        "Brian F. Feldman" <green@FreeBSD.ORG>, arch@FreeBSD.ORG
Subject:   Re: xucred introduction
Message-ID:  <3A819788.DA35F78C@elischer.org>
References:  <2711.981570785@critter>

next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote:
> 
> In message <200102071828.f17ISLr17637@green.dyndns.org>, "Brian F. Feldman" wri
> tes:
> 
> >The only question is whether or not to add some spare fields to
> >xucred now in case we /do/ want to expand it in the future, and also whether
> >it's appropriate to make some of the field type changes (for example,
> >sockaddr length type -> u_char, since that _IS_ what is defined by the
> >sockaddr interface).
> 
> Have you already put a version number in it ?  Otherwise please
> do so.  That is the best way to ensure that we don't get too many
> problems in the future.
> 
> I think in general all structures shared between the kernel and userland
> should be equipped with a version number as the first element.

this brings up whether we should have 'rules' for kernel structures in general..

for example
"Always start with a version number followed by a magic number followed by the
reference count and the lock" or something like that. I know some systems DO
impoes such rules and seem to get advantages from it.  (you can add debug code
to check the magic numbers really easily for example).

Not a REALLY serious suggestion but something to consider.
what would YOU like to see as a standard part of kernel structures?

reference count?
magic number?
generation count?
lock (pointer?)
version number?

I leads to a general discussion about kernel architecture eventually :-)

> 
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message

-- 
      __--_|\  Julian Elischer
     /       \ julian@elischer.org
    (   OZ    ) World tour 2000-2001
---> X_.---._/  
            v


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A819788.DA35F78C>