Ollie Lho <[EMAIL PROTECTED]> writes: > Eric, > With you last CVS change, it seems that you have totally changed > the fill_inbuf structure.
Yes. I have been wanting to optimize it for a while... > Do we still have an area of physical memory to work as buffer ?? Yes. The previous structure with fill_inbuf I think was a little better with respect to sharing a buffer. The current structure is optimized for simply reading just the data neede, and writing it to it's final destination in ram, without processing it, and for skipping over large chunks of unused data. It is perfectly acceptable and encouraged to allocate your own buffers in read and just return what the application actually wants. My recommendation is just a single sector buffer (what ever that is for your device ). >I don't see how you cache a block of data read > form IDE in memory when you call get_byte and stream->read(&result,> 1). The > 'char result' is a local variable on stack, doesn't this cause > overflow ?? The way I implmented get_byte is not at all optimal. I have not broken the non-elf bootloader, in LinuxBIOS main but I'm not enthusiastic about it. Looking more closely at the IDE code which I just adapted... And at the floppy code that I totally wrote... Wow. I really messed on up the caching side. Somehow I had it in my mind that I had a sector or track cache that handled the partial read case. But now that I look at it I simply didn't notice it because I was using the ELF bootloader, which just happens to read nice large blocks of data at a time, into their destination. So my get_byte implementation in do_inflate.c is totally insane. I guess then I should implement a track/sector cache in the fill_inbuf routines. This will avoid the duplicate I/O problem as efficiently as possible. get_byte can probably be optimized also if the non ELF case continues to be important. Keeping a small buffer of bytes around so we don't incur the function call overhead on every byte looks reasonable. The reason we don't have a problem in get_byte for correctness is that we only asked for one byte, and only one byte is returned. But in the most inefficient way possible now that I have given everything a second look. Eric
