We do have 16KB buffer space defined in pxe.c, move it to bio.c and implement
bio_alloc()/bio_free() interface to make it possible to use this space for
other BIOS calls (notably, from biosdisk.c).
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 21280 Build 20616: arc lint + arc unit
Event Timeline
Comment Actions
Generally I like this, but it also looks like there's some drive reset retry logic tossed in as well...
Comment Actions
yes, it is not clean current below this patch - I had D11174 below. I can rebase on current but I would rather keep my own order or I will mix fbsd and illumos up at some point:D
Comment Actions
Couple of minor nits, but otherwise looks OK.
| stand/i386/libi386/biosdisk.c | ||
|---|---|---|
| 472 | speaking of which... We are getting pretty big with all the crazy new features. Is there a reliable way to tell the largest bootable image since it must all fit <= 640k? I run into trouble in the mid 500's... | |
| 952 | you said 16k above? Is that still right or ??? | |
| stand/i386/libi386/biosdisk.c | ||
|---|---|---|
| 472 | not really. The fundamental issue (and also way out in a sense) is the memory layout. The BTX is at 0x9000, loader is starting at 0xa000 - thats code + data + bss. We get the memory size from 0x413 (2 bytes, in pages), and thats basically our initial stack pointer. Since the BDA is variable, we have no way to know ahead how much space we have for sure. However, our stack does not have to be in low memory, we could set it just below the heap too - but that means we wont provide stack variables for BIOS calls. Not too hard to clean up. | |
| 952 | Thats the 1 page from current setup. There is one page in between BTX data areas we are using. if somehow we end up the "bio" area exhausted, this is our fallback. I'd expect it never happen, but ... | |