> I don't see the purpose of having a firmware image permanently
> resident (especially given their sizes). Getting the boot loader to
> directly load the firmware into the device seems a much nicer
> solution. If this is impractical, treating the firmware as a kld and
> unloading it after downl
< said:
> How do you suggest such files get distributed?
cvsup and/or rsync. This does leave CTM-users the odd men out
> As Matt pointed out, CVS provides us with a good mechanism for
> ensuring that I can identify what version of the firmware I am using
> - and be reasonably certain it ma
On Tue, Apr 25, 2000 at 03:27:38AM +1000, Garrett Wollman wrote:
>The fact that said directory is under CVS control, which is what I'm
>suggesting we get away from.
How do you suggest such files get distributed? Everything else is
in the CVS repository and most (if not all) of our build process
On Tue, Apr 25, 2000 at 09:48:18PM +1000, Sheldon Hearn wrote:
>If that's the _only_ point, then Garrett Wollman's idea should work
>perfectly. Stick the files under CVS, just agree that they should
>never be revised, but rather that new versions should be imported in a
>different directory and t
> > If that's the _only_ point, then Garrett Wollman's idea should work
> > perfectly. Stick the files under CVS
>
> No, that was not my proposal. I want to keep them out of CVS
> entirely. CVS is Not Good at handling binary files (even if you never
> change them). That's why I'd like them in
< said:
> If that's the _only_ point, then Garrett Wollman's idea should work
> perfectly. Stick the files under CVS
No, that was not my proposal. I want to keep them out of CVS
entirely. CVS is Not Good at handling binary files (even if you never
change them). That's why I'd like them in a
On Mon, 24 Apr 2000 13:52:20 MST, Matthew Jacob wrote:
> But this isn't the point. The point is to cause less cvsup turbulence
> for all and sundry. I think I can do enough of this by just splitting
> the file apart to keep everyone happy. Or happy enough.
If that's the _only_ point, then Garr
> Matt can tell you more ;-)
People don't really want to know more. They just don't want what I provide
support for to impact them. I'll bet if I sum up all the other kernel mathoms
like netgraph, and so on, that *I* never use, it'd be less than this f/w...:-)
But this isn't the point. The poin
On Mon, Apr 24, 2000 at 02:07:22PM -0500, Richard Wackerbarth wrote:
> On Mon, 24 Apr 2000, you wrote:
>
> > > Seriously, perhaps we should consider putting optional pieces of the
> > > kernel
> >
> > Firmware for a SCSI adapter is not optional. At least not on some of the
> > Alpha machines that
On Mon, 24 Apr 2000, you wrote:
> > Seriously, perhaps we should consider putting optional pieces of the
> > kernel
>
> Firmware for a SCSI adapter is not optional. At least not on some of the
> Alpha machines that download out-of-date firmware from their SRMs so depend
> on the driver to load th
On Mon, Apr 24, 2000 at 01:43:44PM -0500, Richard Wackerbarth wrote:
> On Mon, 24 Apr 2000, Julian Elischer wrote:
>
> > This seems well thought out and I certainly agree that we don't need
> > DIFFs of firmware.
> > I wonder if we can somehow "cheat time" and get that 13MB file out of
> > the so
On Mon, 24 Apr 2000, Julian Elischer wrote:
> This seems well thought out and I certainly agree that we don't need
> DIFFs of firmware.
> I wonder if we can somehow "cheat time" and get that 13MB file out of
> the source tree and retro-actively tag the new scheme so
> that we don't have to carry
> < said:
>
> > This is probably an okay idea, except how would you include such files?
> > I'm not sure I follow your naming scheme in /usr/firmware- what's wrong with
> > /usr/src/sys/dev/firmware/{isp, esh, ...}?
>
> The fact that said directory is under CVS control, which is what I'm
> sugge
< said:
> This is probably an okay idea, except how would you include such files?
> I'm not sure I follow your naming scheme in /usr/firmware- what's wrong with
> /usr/src/sys/dev/firmware/{isp, esh, ...}?
The fact that said directory is under CVS control, which is what I'm
suggesting we get awa
This is probably an okay idea, except how would you include such files?
I'm not sure I follow your naming scheme in /usr/firmware- what's wrong with
/usr/src/sys/dev/firmware/{isp, esh, ...}?
On Mon, 24 Apr 2000, Garrett Wollman wrote:
> < said:
>
> > This seems to be inherent in the file
Garrett Wollman wrote:
>
> < said:
>
> > This seems to be inherent in the file format. Binary data is expanded
> > by a factor of 4 due to encoding it as a C array. Even tiny changes
> > in the data ripple through the array and give huge diffs. Uuencoding
> > the data would only expand it by
< said:
> This seems to be inherent in the file format. Binary data is expanded
> by a factor of 4 due to encoding it as a C array. Even tiny changes
> in the data ripple through the array and give huge diffs. Uuencoding
> the data would only expand it by a factor of 1.4 although it would
> ha
Yes, this needs to be fixed. I have an open bug about this with respect to
making the f/w a loadable module as well. I'll probably split it into several
pieces so that each f/w update is smaller. I could probably make it binary and
compress is (each f/w module is an array of 16 bit shorts), but t
On Mon, 24 Apr 2000, Julian Elischer wrote:
> My cvsup appeared to be frozen, so I stopped it and looked..
>
> src/sys/dev/isp/asm_pci.c,v is 13MB long!
> it was just taking a long time..
>
> this seems a little excessive.
I was annoyed by this a few months ago when the file was only 10MB.
>
19 matches
Mail list logo
