From: Larry McVoy <lm@bitmover.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Larry McVoy <lm@bitmover.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
David Dillow <dillowd@y12.doe.gov>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-net@vger.kernel.org, Jeff Garzik <jgarzik@pobox.com>
Subject: Re: 3Com 3cr990 driver release
Date: Fri, 14 Feb 2003 10:44:58 -0800 [thread overview]
Message-ID: <20030214184458.GA1488@work.bitmover.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0302141916490.32518-100000@serv>
On Fri, Feb 14, 2003 at 07:40:32PM +0100, Roman Zippel wrote:
> Hi,
>
> On Fri, 14 Feb 2003, Larry McVoy wrote:
>
> > And what format lockin? It's an open format, GNU CSSC reads and writes
> > it just fine, and we've made a point over the years of telling them each
> > time we change something so that they can continue to read/write our
> > files. More FUD.
>
> Are these changes/extensions documented somewhere or is a patch available?
> My version of cssc certainly has a few problems, without patching it's
> very noisy.
The only change is to accept ^AHxxxxx as well as ^Ahxxxxx as the per file
checksum. I'm almost positive that someone posted a patch to the kernel
which made CSSC like BK files.
If the BK files are compressed, you have to uncompress them first and you
can't use gunzip to do so, you have to use BK. You could teach CSSC to
read our compressed files if you like, there is no secret to how we do
that, the top part of the file containing the graph is uncompressed and
the rest is compressed, so you have to tickle the code into being able to
start uncompressing at an offset other than 0.
The only other difference I know of is that we support files without newlines
at the end of the file and CSSC doesn't (and I don't blame them, it is
dramatically more difficult than you might think at first glance).
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
next prev parent reply other threads:[~2003-02-14 18:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-14 7:50 3Com 3cr990 driver release David Dillow
2003-02-14 8:20 ` Jeff Garzik
2003-02-14 14:33 ` Alan Cox
2003-02-14 15:19 ` Larry McVoy
2003-02-14 16:54 ` Alan Cox
2003-02-14 16:09 ` Larry McVoy
2003-02-14 17:23 ` Alan Cox
2003-02-14 16:36 ` Larry McVoy
2003-02-14 17:04 ` Tomas Szepe
2003-02-14 17:12 ` Larry McVoy
2003-02-14 18:40 ` Roman Zippel
2003-02-14 18:44 ` Larry McVoy [this message]
2003-02-14 18:59 ` Roman Zippel
2003-02-15 11:34 ` Henning P. Schmiedehausen
2003-02-14 17:28 ` Alan Cox
2003-02-14 23:01 ` Steven Cole
2003-02-14 17:20 ` David Dillow
2003-02-14 20:52 ` Alan Cox
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=20030214184458.GA1488@work.bitmover.com \
--to=lm@bitmover.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dillowd@y12.doe.gov \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
--cc=zippel@linux-m68k.org \
/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