Linux NFS development
 help / color / mirror / Atom feed
From: "George Spelvin" <linux@horizon.com>
To: linux@horizon.com, Trond.Myklebust@netapp.com
Cc: linux-nfs@vger.kernel.org, lm@bitmover.com
Subject: Re: kernel BUG at /build/buildd/linux-3.2.0/fs/lockd/clntxdr.c:226!
Date: 16 Oct 2012 00:39:46 -0400	[thread overview]
Message-ID: <20121016043946.13851.qmail@science.horizon.com> (raw)
In-Reply-To: <4FA345DA4F4AE44899BD2B03EEEC2FA909253B3B@SACEXCMBX04-PRD.hq.netapp.com>

> Well, I'm really glad to hear that after several people spent 3-4 hours
> debugging an NFSv2-only server side problem last Friday. Please let me
> know the next time I can help deal with another fairly simple matter of
> old compatibility calls...

I didn't mean to rouse the sarcasm monster; I was, at your prompting,
investigating the effort of maintaining it myself.

Your .sig says "NFS client", I didn't see your name a lot in the fs/nfsd
directory changelogs, and I wondered, so I *asked*.

> OK, I'll bite. What is this business-critical application that you are
> running and that will only run on a machine that is incapable of running
> a mere 20-year old protocol and that must have a 30 year old protocol?

It's the firmware for an old embedded product, which I still do occasional
fixes for.  The compiler it's been developed with is a binary from
a company that's long out of business, so I'm stuck running the old
binary on the old OS.  (The product itself doesn't date back to 1990,
but the source code archives do, since the same platform was used for
earlier products.)

Yes, I *could* just port the whole thing over to GCC, but like most
embedded code, it's very sensitive to the environment, probably makes
some non-ANSI assumptions that will anger GCC's optimizer, *does* use
a different calling convention that will require fixing all the
assembly routines, and it would require a LOT of re-testing.

Since what we have now has decades of testing, and I'd rather spend my
time developing new products, keeping everything limping along has a
lot of advantages.

My most recent changes were in February 2011: an unusual combination
of commands could cause a lockup.  Before that was adding a new baud
rate a customer needed in July 2010.  There is very little effort,
but maintaining the capability is important.

I actually tried to compile git on SunOS, but things Didn't Work Well,
so what I do is do source control on the Linux NFS server, and just
use the old machine for the actual compiles.

> The fact that you are all in a huff about base64 encoded emails
> indicates that this is not something you are running on anything as
> sophisticated as a cell phone.

I didn't mean to come across as *that* peeved about the base64; it's
mostly annoying because I can't grep my mailbox, and my preferred
mailing list archive web interface (marc.info) doesn't decode them.
And it seems perverse for an MUA to encode something as base-64 that is
100% 7-bit ASCII.  If nothing else, it bloats the message size 35%.

  reply	other threads:[~2012-10-16  4:39 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-15  8:05 kernel BUG at /build/buildd/linux-3.2.0/fs/lockd/clntxdr.c:226! George Spelvin
2012-10-15 12:19 ` Myklebust, Trond
2012-10-15 16:02   ` VDR User
2012-10-16  1:48   ` George Spelvin
2012-10-16  1:52     ` Larry McVoy
2012-10-16  3:46     ` Myklebust, Trond
2012-10-16  4:39       ` George Spelvin [this message]
2012-10-16 11:17       ` Jim Rees
     [not found] <20121012211701.GA8301@bitmover.com>
2012-10-12 23:52 ` Linus Torvalds
2012-10-13  0:21   ` Larry McVoy
2012-10-13  1:02     ` Linus Torvalds
2012-10-13  1:36       ` Jim Rees
2012-10-13  1:45         ` Linus Torvalds
2012-10-13 21:31           ` Daniel Kahn Gillmor
2012-10-13  2:08         ` Boaz Harrosh
2012-10-13  2:28       ` Myklebust, Trond
2012-10-13  2:31         ` Larry McVoy
2012-10-13  2:52           ` Myklebust, Trond
2012-10-13  2:56             ` Larry McVoy
2012-10-13  3:05               ` Myklebust, Trond
2012-10-13  4:42               ` Myklebust, Trond
2012-10-14  1:42                 ` Larry McVoy
2012-10-15  0:43                   ` Bruce Fields
2012-10-15  4:38                     ` Myklebust, Trond
2012-10-15 14:34                       ` Larry McVoy
2012-10-15 18:02                         ` Bruce Fields
2012-10-15  4:41                     ` Myklebust, Trond
2012-10-15 12:11                       ` Bruce Fields
2012-10-17 14:00                 ` Bruce Fields
2012-10-14 19:39         ` Bruce Fields
2012-10-14 19:44           ` Linus Torvalds
2012-10-14 20:55           ` Chuck Lever
2012-10-14 21:05             ` Linus Torvalds
2012-10-14 22:32               ` Chuck Lever
2012-10-14 22:54                 ` Linus Torvalds
2012-10-13  2:27   ` Boaz Harrosh
2012-10-13  2:30     ` Larry McVoy
2012-10-13  2:32     ` Myklebust, Trond
2012-10-13  2:39       ` Boaz Harrosh
2012-10-13  2:43         ` Larry McVoy
2012-10-14 19:43         ` Bruce Fields
2012-10-15 18:20           ` Boaz Harrosh
2012-10-13  2:37     ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121016043946.13851.qmail@science.horizon.com \
    --to=linux@horizon.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=lm@bitmover.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox