On Mon, Oct 28, 2002 at 04:27:36PM -0600, David Thompson wrote:
> Especially if there is no client-side caching, you might as well run a
> read-only samba and/or nfs server, and mount the data using those
> protocols. You could even run the translator on the file server(s)
> themselves.
If you've
On Mon, 2002-10-28 at 17:27, David Thompson wrote:
> Matthew Miller wrote:
> >On Fri, Oct 25, 2002 at 10:30:28PM -0400, Tim C. wrote:
> >> Another great use of this, we at UMBC have a /usr/local in afs space that
> >> most clients are linked to. If there was some computer that didn't really n
>
Matthew Miller wrote:
>On Fri, Oct 25, 2002 at 10:30:28PM -0400, Tim C. wrote:
>> Another great use of this, we at UMBC have a /usr/local in afs space that
>> most clients are linked to. If there was some computer that didn't really n
>eed
>> access to afs cause it had all their files locally, t
On Fri, Oct 25, 2002 at 10:30:28PM -0400, Tim C. wrote:
> Another great use of this, we at UMBC have a /usr/local in afs space that
> most clients are linked to. If there was some computer that didn't really need
> access to afs cause it had all their files locally, then it could use this
> read
> > It's got grandiose plans for getting better. In any case, I can
> > definitely see a place for a lightweight read-only client -- for most of
> > our users, that's all they do.
>
> Certainly not ours. An unauthenticated client or a client without write
> access strikes me as practically worthle
Matthew Miller <[EMAIL PROTECTED]> writes:
> It's got grandiose plans for getting better. In any case, I can
> definitely see a place for a lightweight read-only client -- for most of
> our users, that's all they do.
Certainly not ours. An unauthenticated client or a client without write
access
On Tue, 22 Oct 2002, Hartmut Reuter wrote:
> Derrick J Brashear wrote:
>
> > We *may* need:
> > -rx performance enhancements. nobody has yet quantified that it's really
> > rx and not a client or server issue, but i suspect what Hartmut has
> > pointed at indicates a direction: SMP linux kernel on
Derrick J Brashear wrote:
We *may* need:
-rx performance enhancements. nobody has yet quantified that it's really
rx and not a client or server issue, but i suspect what Hartmut has
pointed at indicates a direction: SMP linux kernel on UP machine performs
better.
I must admit this was not an rx
--On Tuesday, October 22, 2002 11:26:05 -0400 Derek Atkins
<[EMAIL PROTECTED]> wrote:
How is AFS supposed to use an open/read/write/close method to hook
into, e.g., initgroups()?
I guess I was imprecise. Derrick's patch dealt only with sys_afs, not
sys_setgroups. We were planning on praying fo
On 22 Oct 2002, Derek Atkins wrote:
> > Derrick tried to submit a patch that implimented "safe" syscall
> > registration modeled on nfsservctl, and got nothing but pushback about
> > how dispatching interfaces suck, and that instead afs should use an
> > "open/read/write/close" method. This wasn't
On 22 Oct 2002, seth vidal wrote:
> Therein lies the rub. I guess it will just be a question of which one
> does it better over the long run. Just like the many conflicting ACL
> systems trying to get in the kernel or VM subsystems.
Not "competing ACL systems". This would be "competing implementa
On Tue, 22 Oct 2002, chas williams wrote:
> In message <[EMAIL PROTECTED]>,Derek Atkins writes:
> >Oh, he merged in that crap? Damn. It's a read-only,
> >no-authentication, no-vlserver-lookup AFS client. What's
> >the point?
>
> dont worry. they are going to write that part. and it will
> be
On 22 Oct 2002, Derek Atkins wrote:
> Oh, he merged in that crap? Damn. It's a read-only,
> no-authentication, no-vlserver-lookup AFS client. What's
> the point?
I would assume it's progressed since then. Wasn't there read-only UFS
before rw existed, and so on? I suppose no precedent when othe
Chaskiel M Grundman <[EMAIL PROTECTED]> writes:
> --On Tuesday, October 22, 2002 09:36:40 -0400 Derek Atkins
> <[EMAIL PROTECTED]> wrote:
> > Why would Red Hat specifically care about OpenAFS? In particular, why
> > would they care about making it fail to work?
>
> Perhaps because they want us t
On Tue, 22 Oct 2002, Neulinger, Nathan wrote:
> Probably not redhat, but Alan Cox. I believe he has been very vocal in
> the past against our using syscall hooks.
Actually, check your references better. He suggested we could use a hook,
not that we shouldn't. I know my references are right, my re
--On Tuesday, October 22, 2002 09:36:40 -0400 Derek Atkins
<[EMAIL PROTECTED]> wrote:
Why would Red Hat specifically care about OpenAFS? In particular, why
would they care about making it fail to work?
Perhaps because they want us to fix our "hideous" interfaces, and wanted us
to stop waiting
On Tue, 2002-10-22 at 10:26, Derek Atkins wrote:
> seth vidal <[EMAIL PROTECTED]> writes:
>
> > Not disputing that - but then again - the nfs stack in the kernel won't
> > work elsewhere either. Doesn't seem to concern the kernel development
> > people.
>
> Except there was never a pre-existing,
seth vidal <[EMAIL PROTECTED]> writes:
> Not disputing that - but then again - the nfs stack in the kernel won't
> work elsewhere either. Doesn't seem to concern the kernel development
> people.
Except there was never a pre-existing, portable implementation
of in-kernel NFS, to the analogy doesn'
On Tue, 2002-10-22 at 10:23, Derek Atkins wrote:
> seth vidal <[EMAIL PROTECTED]> writes:
>
> > > The problem is that there are a LOT of AFS projects that need to get
> > > done and a complete lack of developer resources to do them. While
> > > another implementation is an interesting thing theor
seth vidal <[EMAIL PROTECTED]> writes:
> > The problem is that there are a LOT of AFS projects that need to get
> > done and a complete lack of developer resources to do them. While
> > another implementation is an interesting thing theoretically,
> > practically it will slow down deployment of n
On Tue, 2002-10-22 at 10:17, Derek Atkins wrote:
> seth vidal <[EMAIL PROTECTED]> writes:
>
> > I think the point is that it is a gpld afs client so it can be shipped
> > IN the kernel - and it's a place to start.
>
> Open Source is Open Source. So AFS uses the IPL instead of the GPL.
> So what?
On Tue, Oct 22, 2002 at 10:17:46AM -0400, Derek Atkins wrote:
> Open Source is Open Source. So AFS uses the IPL instead of the GPL.
> So what? It's still a perfectly valid license. If they were going to
Sure, it's a valid license, but it's not GPL-compatible, so it *can't* go in
the kernel.
-
seth vidal <[EMAIL PROTECTED]> writes:
> I think the point is that it is a gpld afs client so it can be shipped
> IN the kernel - and it's a place to start.
Open Source is Open Source. So AFS uses the IPL instead of the GPL.
So what? It's still a perfectly valid license. If they were going to
In message <[EMAIL PROTECTED]>,Derek Atkins writes:
>Oh, he merged in that crap? Damn. It's a read-only,
>no-authentication, no-vlserver-lookup AFS client. What's
>the point?
dont worry. they are going to write that part. and it will
be bug free and prefect. it does seem like a waste to rewr
On Tue, Oct 22, 2002 at 10:10:53AM -0400, Derek Atkins wrote:
> Oh, he merged in that crap? Damn. It's a read-only,
> no-authentication, no-vlserver-lookup AFS client. What's
> the point?
It's got grandiose plans for getting better. In any case, I can definitely
see a place for a lightweight re
On Tue, 2002-10-22 at 10:05, Derek Atkins wrote:
> "Neulinger, Nathan" <[EMAIL PROTECTED]> writes:
>
> > Probably not redhat, but Alan Cox. I believe he has been very vocal in
> > the past against our using syscall hooks.
>
> Except Alan does not work for Red Hat, and you will notice that these
>
On Tue, 2002-10-22 at 10:10, Derek Atkins wrote:
> Oh, he merged in that crap? Damn. It's a read-only,
> no-authentication, no-vlserver-lookup AFS client. What's
> the point?
>
I think the point is that it is a gpld afs client so it can be shipped
IN the kernel - and it's a place to start.
Th
Oh, he merged in that crap? Damn. It's a read-only,
no-authentication, no-vlserver-lookup AFS client. What's
the point?
-derek
Matthew Miller <[EMAIL PROTECTED]> writes:
> On Tue, Oct 22, 2002 at 09:36:40AM -0400, Derek Atkins wrote:
> > Why would Red Hat specifically care about OpenAFS? In
On Tue, Oct 22, 2002 at 09:36:40AM -0400, Derek Atkins wrote:
> Why would Red Hat specifically care about OpenAFS? In particular, why
> would they care about making it fail to work?
I'm not advocating a conspiracy theory, but it's worth noting that Linus
recently merged a lightweight kernel-based
Grundman
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [OpenAFS-devel] Updated redhat workaround patch
> >
> >
> > Chaskiel M Grundman <[EMAIL PROTECTED]> writes:
> >
> > > --On Tuesday, October 22, 2002 11:17:03 +0200 Frank Bagehorn
> > > <[
: (573) 341-4841
Computing Services Fax: (573) 341-4216
> -Original Message-
> From: Derek Atkins [mailto:warlord@;MIT.EDU]
> Sent: Tuesday, October 22, 2002 8:37 AM
> To: Chaskiel M Grundman
> Cc: [EMAIL PROTECTED]
> Subject: Re: [OpenAFS-dev
Chaskiel M Grundman <[EMAIL PROTECTED]> writes:
> --On Tuesday, October 22, 2002 11:17:03 +0200 Frank Bagehorn
> <[EMAIL PROTECTED]> wrote:
>
> > What would be the sense in leaving out kallsyms_symbol_to_address and
> > keeping kallsyms_address_to_symbol ?
> My personal suspicion is that it was i
--On Tuesday, October 22, 2002 11:17:03 +0200 Frank Bagehorn
<[EMAIL PROTECTED]> wrote:
What would be the sense in leaving out kallsyms_symbol_to_address and
keeping kallsyms_address_to_symbol ?
My personal suspicion is that it was intended to specifically break my
previous patch. hence the dia
Derek Atkins wrote:
>Frank Bagehorn <[EMAIL PROTECTED]> writes:
>
>> I still would consider the missing symbols as a bug in the new kernel.
>> What would be the sense in leaving out kallsyms_symbol_to_address and
>> keeping kallsyms_address_to_symbol ?
>> It's very easy to add the export statemen
Frank Bagehorn <[EMAIL PROTECTED]> writes:
> I still would consider the missing symbols as a bug in the new kernel.
> What would be the sense in leaving out kallsyms_symbol_to_address and
> keeping kallsyms_address_to_symbol ?
> It's very easy to add the export statements for the two missing fun
I still would consider the missing symbols as a bug in the new kernel.
What would be the sense in leaving out kallsyms_symbol_to_address and
keeping kallsyms_address_to_symbol ?
It's very easy to add the export statements for the two missing functions
to .../linux/kernel/ksyms.c and re-compile t
It seems as though I forgot to use diff -N when generating the patch.
Attached is the missing file (linux-test5.m4) It should go into src/cf
AC_DEFUN(OPENAFS_GCC_SUPPORTS_MARCH, [
AC_MSG_CHECKING(if $CC accepts -march=pentium)
save_CFLAGS="$CFLAGS"
CFLAGS="-MARCH=pentium"
AC_CACHE_VAL(openafs_gc
37 matches
Mail list logo
