On Tuesday, January 02, 2007 06:20:36 PM -0500 Marcus Watts <[EMAIL PROTECTED]>
wrote:
OpenAFS has its own local set of conventions which have evolved but
don't seem to be well documented or consistently followed. There's
some stuff in README.DEVEL (from [EMAIL PROTECTED] )
Not me. CVS l
In message <[EMAIL PROTECTED]>,Marcus Watts writes:
>Yes, I know inline functions can do nifty things, but I also think of
>this as being in part a pernicious influence from c++. The problem
>with inline functions is that it's easy to abuse them to get bad code
>bloat, and debugging anything real
On Jan 4, 2007, at 22:15, Derrick J Brashear wrote:
Er, sorry, I didn't mean to approve that.
You enjoyed the heated discussion before and wanted to experience it
again? ;)
-rob
___
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://li
Er, sorry, I didn't mean to approve that.
___
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel
I'm kind of looking for some guidance in this email as well as to
proffer some changes in a few realms, including OS rev. support cut-
off, conversion to vn_alloc(), and a en masse cleaning up of src/afs/
SOLARIS code.
1) Proposal to cut off support for revisions less than Solaris 2.6.
To
"Sean O'Malley" <[EMAIL PROTECTED]> writes:
> From: "Sean O'Malley" <[EMAIL PROTECTED]>
> To:
> In-Reply-To: <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
> Subject: Re: [OpenAFS-devel] Refactoring the Solaris libafs cod
> We have about 5 compiler toolsets we are using. We have GNU, Sun, IBM, M$,
> HP, SGI?, Cray? and ??.
Yes, I use SGI's compiler for Irix.
(I have the following OSes where I can't use GNU because of the kernel
module: Solaris, AIX, Irix).
Harald.
___
;[EMAIL PROTECTED]>
> Subject: Re: [OpenAFS-devel] Refactoring the Solaris libafs code base
> Date: Wed, 03 Jan 2007 10:43:17 -0500
>
> In message <[EMAIL PROTECTED]>,Marcus Watts writes:
> >OpenAFS has its own local set of conventions which have evolved but
> >do
I am know I am probably some of the cause of fixing header files, and my
sincere apologies.
We have about 5 compiler toolsets we are using. We have GNU, Sun, IBM, M$,
HP, SGI?, Cray? and ??. QNX, BSDi, Ultrix, Next, AT&T, Vax, SunOS (bsd),
and ?? are all deprecated. Linux, and the BSDs (open, free
In message <[EMAIL PROTECTED]>,Marcus Watts writes:
>OpenAFS has its own local set of conventions which have evolved but
>don't seem to be well documented or consistently followed. There's
>some stuff in README.DEVEL (from [EMAIL PROTECTED] ) but it's missing anything
>on
>include files. It's ne
On Jan 2, 2007, at 10:17 PM, Jim Rees wrote:
This made it impossible to just build the kernel module,
and made it possible to edit one copy of the source while the
compiler was
building the other copy.
... which I guess would have been handy considering how long a full
compile session pro
I just checked the v7 command source. System includes aren't always first,
but they are usually grouped together with either types.h or param.h first.
I don't know the history of style(9) but I know it's in all the bsds now.
If someone does this, they may also want to do something
about the
Jim Rees <[EMAIL PROTECTED]> writes:
...
> If anyone is seriously considering refactoring the includes, I wish you good
> luck. It's a job that needs doing.
>
> Please try to stick to the original unix include guidelines:
>
> first either sys/types or sys/param but not both
> then sys/*
> then n
I suspect that's because INN doesn't make heavy use of kernel interfaces. I
know that I've spent a fair amount of time fixing the order of includes in
afs code recently.
___
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/m
Jim Rees <[EMAIL PROTECTED]> writes:
> If anyone is seriously considering refactoring the includes, I wish you
> good luck. It's a job that needs doing.
> Please try to stick to the original unix include guidelines:
> first either sys/types or sys/param but not both
> then sys/*
> then net/* an
If anyone is seriously considering refactoring the includes, I wish you good
luck. It's a job that needs doing.
Please try to stick to the original unix include guidelines:
first either sys/types or sys/param but not both
then sys/*
then net/* and other system includes
then stdio and other user
> On Sat, 30 Dec 2006, Marcus Watts wrote:
>
> > Kernel side building is not nearly as standardized; there is no
> > completely portable way to handle includes. Since the kernel isn't
> > (usually) linked against libc, many functions that are present in
> > userland code aren't present inside the
On Sat, 30 Dec 2006, Marcus Watts wrote:
> Kernel side building is not nearly as standardized; there is no
> completely portable way to handle includes. Since the kernel isn't
> (usually) linked against libc, many functions that are present in
> userland code aren't present inside the kernel, so
Matt Benjamin wrote:
> In some ways, this sounds attractive. However, do you think this might
> make the Windows platform more complex (costly) to support?
>
> Matt
I have to write the kernel interfaces away in order to process the
requests. The question is do we want to incur the overhead of
In some ways, this sounds attractive. However, do you think this might
make the Windows platform more complex (costly) to support?
Matt
Jeffrey Altman wrote:
Marcus Watts wrote:
Windows, of course, has no kernel component today. It might
sprout one in the future, but if so, it's likely
Marcus Watts wrote:
> Windows, of course, has no kernel component today. It might
> sprout one in the future, but if so, it's likely to be just
> a small special purpose stub driver that redirects to a userland
> daemon (at least that's what everyone's done with IFS + afs so far).
My plan is to m
Russ had sent this list earlier:
...
> At least in user-space code (I don't know if kernel-space is special), at
> least all of the following C headers can be included without any guards on
> any Unix platform we care about:
>
> errno.h
> fcntl.h
> stdarg.h
> stdio.h
> stdlib.h
> string.h
> sys/sta
Sean O'Malley wrote:
> I just have a question on the this list Russ listed for std includes.
>
> There are a bunch of:
> #ifdef KERNEL
> #include "afs/param.h"
> #else
> #include
> #endif
> -from src/util/netutils.c
>
> Does this mean at some point this code gets used by kernel routines?
> and I
I just have a question on the this list Russ listed for std includes.
There are a bunch of:
#ifdef KERNEL
#include "afs/param.h"
#else
#include
#endif
-from src/util/netutils.c
Does this mean at some point this code gets used by kernel routines?
and I need to be more careful about removing the i
Jeffrey Altman <[EMAIL PROTECTED]> writes:
> Are there any symbols from fcntl.h that are being used by anything other
> than code within AFS_NT40_ENV ?
> I prefer to pull in as few headers as necessary to correctly compile
> the code.
It's a lot of this sort of nonsense:
#ifdef AFS_NT40_ENV
#in
Sean O'Malley wrote:
> On Thu, 28 Dec 2006, Jeffrey Altman wrote:
>
>> I've re-read the above sentences several times now. I'm not sure I
>> understand which inclusions of fcntl.h you are referring to. Do you
>> build the Windows tree? If not, I would leave it alone.
>>
>> The Microsoft compil
On Thu, 28 Dec 2006, Russ Allbery wrote:
> I suppose that means I should take on reviewing and applying the patch.
I will rewrite it to avoid where kernel is defined and take out the ifdef
for string and resubmit it later. It will cut the size of it down quite a
bit which means less reviewing. :)
On Thu, 28 Dec 2006, Jeffrey Altman wrote:
> I've re-read the above sentences several times now. I'm not sure I
> understand which inclusions of fcntl.h you are referring to. Do you
> build the Windows tree? If not, I would leave it alone.
>
> The Microsoft compilers have included fcntl.h goin
Jeffrey Altman <[EMAIL PROTECTED]> writes:
> The Microsoft compilers have included fcntl.h going back at least a
> decade. HAVE_FCNTL_H is defined in the windows config.h file. So if
> you are asking if #ifdef HAVE_FCNTL_H can be removed, the answer from
> the perspective of Windows is 'yes' but
Sean O'Malley wrote:
> Is it consensus that I can eliminate the ifdef's for fcntl.h in the
> windows code and just include it? (there are a number of places where it
> is ifdef'd to be included for windows or NT4.. )
I've re-read the above sentences several times now. I'm not sure I
understand wh
I can rewrite the patch, I -know- it is ugly. I was just trying not to
break anything and stole that ifdef line from another part of the code. :)
Should I wait until the other mega-patch is applied to the trunk?
Is it consensus that I can eliminate the ifdef's for fcntl.h in the
windows code and
Dale Ghent <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> At least in user-space code (I don't know if kernel-space is special), at
>> least all of the following C headers can be included without any guards on
>> any Unix platform we care about:
>>
> ...
>> string.h
> Not this one, at leas
Russ Allbery wrote:
At least in user-space code (I don't know if kernel-space is special), at
least all of the following C headers can be included without any guards on
any Unix platform we care about:
...
string.h
Not this one, at least on Solaris. It collides with if
_KERNEL is defined.
Marcus Watts <[EMAIL PROTECTED]> writes:
> fcntl.h has been in bsd since 4.2, in AT&T since system III, in SunOS
> since it was called Sun UNIX, and in linux since presumably its start.
> Since it's clearly in windows a well, it should be safe to include it
> everywhere needed with no configure te
Many wrote:
...
> Russ Allbery wrote:
> >> #ifdef HAVE_FCNTL_H
> >> #include
> >> #endif
> >
> > There is no need to ifdef fcntl.h unless the code has to also compile on
> > Windows (and there, I'm not sure if fcntl.h is available or not). We
> > don't care about SunOS any more.
>
> fcntl.h is
Russ Allbery wrote:
>> #ifdef HAVE_FCNTL_H
>> #include
>> #endif
>
> There is no need to ifdef fcntl.h unless the code has to also compile on
> Windows (and there, I'm not sure if fcntl.h is available or not). We
> don't care about SunOS any more.
fcntl.h is available on Windows. The typical i
Sean O'Malley <[EMAIL PROTECTED]> writes:
> I -just- submitted a patch to clean up missing string.h headers.
> basically it either added a string.h header file or changed #include
> to:
> #ifdef HAVE_STRING_H
> #include
> #else
> #ifdef HAVE_STRINGS_H
> #include
> #endif
> #endif
Surely we do
On Mon, 25 Dec 2006, Dale Ghent wrote:
>
> 1) Proposal to cut off support for revisions less than Solaris 2.6.
Okay by me, I think we phased out all of our solaris 7 machines, and if
some of our machines had more then 256M of RAM solaris 8 would probably be
gone too.
> 2) Clean up src/afs/SOLARI
On Mon, 25 Dec 2006, Dale Ghent wrote:
I'm kind of looking for some guidance in this email as well as to proffer
some changes in a few realms, including OS rev. support cut-off, conversion
to vn_alloc(), and a en masse cleaning up of src/afs/SOLARIS code.
1) Proposal to cut off support for
Dale Ghent <[EMAIL PROTECTED]> writes:
...
> 1) Proposal to cut off support for revisions less than Solaris 2.6.
>
> To be honest, my own opinion is that even 2.6 is too old to care
> about and Solaris 7 is such a stepchild that the cut-off should be
> 8... even as far as Sun is concerned, 2.6
Dale Ghent wrote:
> Raise your hand if you have a 2.5.1
> or lower server where you always absoltively, posolutely need the latest
> afs client on it. Anyone?
Such a question should be asked on openafs-info not on openafs-devel.
You need to obtain the opinion of end users not the very small subse
I'm kind of looking for some guidance in this email as well as to
proffer some changes in a few realms, including OS rev. support cut-
off, conversion to vn_alloc(), and a en masse cleaning up of src/afs/
SOLARIS code.
1) Proposal to cut off support for revisions less than Solaris 2.6.
To
42 matches
Mail list logo
