Re: asm_pci.h,v Holy cow!
> 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 downloading the firmware would seem the next best > option. There's an open PR on this one. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
< 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 matches the code that Matt (or > whoever) validated. So would simply naming the files by version. This works because most if not all of our drivers use firmware from another vendor with its own version-numbering scheme. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
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 is designed around it. 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 matches the code that Matt (or whoever) validated. >The files can be compiled into the kernel very easily using `file2c', >or simply loaded directly by the boot loader. 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 downloading the firmware would seem the next best option. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
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 the old versions punted to the Attic. AFAIK, ctm (not sure about CVSup) doesn't support a rename function - when a file is deleted into the Attic, ctm deletes the old file and then creates a new file in the Attic (transferring the content). So this approach probably wouldn't solve Julian's immediate problem. Apart from that, this approach seems significantly better than (effectively) committing diffs to binary files. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
> > 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 separate hierarchy. Actually, CVS1.10 is *MUCH* better at handling binary files, although you must be sure to set them up as binary files. It works cross-platform and such, but if the file is not added as a binary file, it really gets nasty. ;( (Plus all of the size bloating issues, but that's a seperate issue IMO). Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
< 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 separate hierarchy. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
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 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 the old versions punted to the Attic. The only thing I'd like different from Garrett's proposal is the pathing. I'd prefer to use a general rule for this anywhere in the tree, not just in a path/to/firmware directory. In other words... src/sys/dev/isp/firmware/4.65.00/asm_pci.h Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
> 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 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. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
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 download out-of-date firmware from their SRMs so depend > > on the driver to load them with something up-to-date. > > Sure it is. I certainly have a fine system without any SCSI adapter. > > The whole move toward loadable modules is to make the kernel into a > "cafeteria" rather than a "blue plate". > > That firmware is a required part of a particular driver is not in dispute. People were writing "port", not "module". For the isp firmware it is in some cases a mandatory part, in some cases a optional part of the driver. Matt can tell you more ;-) -- Wilko Bulte Powered by FreeBSD http://www.freebsd.org http://www.tcja.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
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 them with something up-to-date. Sure it is. I certainly have a fine system without any SCSI adapter. The whole move toward loadable modules is to make the kernel into a "cafeteria" rather than a "blue plate". That firmware is a required part of a particular driver is not in dispute. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
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 source tree and retro-actively tag the new scheme so > > that we don't have to carry it around forever :-) > > It looks like a port, > Smells like a port, > and tastes like a port. > It must be a . > > merlot ? > > 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 them with something up-to-date. -- Wilko Bulte Powered by FreeBSD http://www.freebsd.org http://www.tcja.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
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 it around forever :-) It looks like a port, Smells like a port, and tastes like a port. It must be a . merlot ? Seriously, perhaps we should consider putting optional pieces of the kernel (eventually much of it, I hope) into a ports style structure. This structure can already take care of most of the problems like this one because it has multiple mechanisms whereas the source tree has only one. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
> < 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 away from.
Umm, then I sure don't get what you're wanting to do.
>
> The files can be compiled into the kernel very easily using `file2c',
> or simply loaded directly by the boot loader.
>
I put in maybe 40-80 hours testing per f/w upgrade. There has to be some
assurance that what you load is correct. CVS does give some assurance of
strong versioning.
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
< 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 away from.
The files can be compiled into the kernel very easily using `file2c',
or simply loaded directly by the boot loader.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED] | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
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 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
> > have the same problem with the diffs.
>
> I've been thinking about this recently myself. We want to maintain
> the ability to examine historical versions of the code, but actual
> diffs from one version to another are, in this context, meaningless.
>
> I'd like to suggest a new hierarchy /usr/firmware, which sits
> along-side /usr/src and /usr/ports in our distribution mechanism, but
> which does not use RCS files to store version information. Rather,
> the version information is encoded in the pathname, and files are
> stored and transferred as binary objects. It might look something
> like this:
>
> /usr/firmware/
> gronk/ (this is the gronk driver)
> 3.57.OA.bin (where 3.57.OA is vendor's version)
> plugh/
> 42.69/
> model1.bin
> model2.bin
> model3.bin
>
> -GAWollman
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
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 a factor of 1.4 although it would > > have the same problem with the diffs. > > I've been thinking about this recently myself. We want to maintain > the ability to examine historical versions of the code, but actual > diffs from one version to another are, in this context, meaningless. > > I'd like to suggest a new hierarchy /usr/firmware, which sits > along-side /usr/src and /usr/ports in our distribution mechanism, but > which does not use RCS files to store version information. Rather, > the version information is encoded in the pathname, and files are > stored and transferred as binary objects. It might look something > like this: > > /usr/firmware/ > gronk/ (this is the gronk driver) > 3.57.OA.bin (where 3.57.OA is vendor's version) > plugh/ > 42.69/ > model1.bin > model2.bin > model3.bin > > -GAWollman 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 it around forever :-) -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
< 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 > have the same problem with the diffs. I've been thinking about this recently myself. We want to maintain the ability to examine historical versions of the code, but actual diffs from one version to another are, in this context, meaningless. I'd like to suggest a new hierarchy /usr/firmware, which sits along-side /usr/src and /usr/ports in our distribution mechanism, but which does not use RCS files to store version information. Rather, the version information is encoded in the pathname, and files are stored and transferred as binary objects. It might look something like this: /usr/firmware/ gronk/ (this is the gronk driver) 3.57.OA.bin (where 3.57.OA is vendor's version) plugh/ 42.69/ model1.bin model2.bin model3.bin -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
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 that has it's onw problems. You should note, btw, that my link isn't all *that* faster than yours (I have 144Kbit DSL). Sorry about the large enchilada. 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. > > anyone got any ideas. (13MB on a 40Kbit link is a long time) > > to make matters worse cvsup appears to be redownloading some very large > percentage of this file whenerver there is a change to it. > > -- > __--_|\ Julian Elischer > / \ [EMAIL PROTECTED] > ( OZ) World tour 2000 > ---> X_.---._/ presently in: Perth > v > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: asm_pci.h,v Holy cow!
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. > anyone got any ideas. (13MB on a 40Kbit link is a long time) Use CTM on slow links :-). > to make matters worse cvsup appears to be redownloading some very large > percentage of this file whenerver there is a change to it. 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 have the same problem with the diffs. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
