packet-0.0.2l-as2, an incremental release to packet-0.0.2l-as it works (at least should) with kernels 2.4.5 2.4.6-pre1 2.4.6-pre2 Other changes, as from ChangeLog: 0.0.2l-as2 (09/06/2001) - updated FAQ to mention mailing list archives - renamed patches and updated install instructions to include only kernel version the patch is against. No point to inclue patch version in file name as it is defined in the files pktcdvd.c and udf_fs.h already - removed changelog from pktcdvd.c and prepended to ChangeLog file - removed todo notes from pktcdvd.c and put it into TODO file. - updated pktcd version to 0.0.02l-as2 in pktcdvd.c - updated INSTALL notes, and mention what kernel it works with. more tech details: there's a new patch for packet for 2.5.6-pre2 as old one would not apply cleanly. if you are curious what change you can use interdiff -p1 packet-2.4.5 packet-2.4.6-pre2 but it is just basically some stuff moved around you don't apply udf patch for 2.5.6-pre2 anymore as it comes with UDF 0.9.4 which is more recent than what used to be distributed with packet-writing package. -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers
On Sat, 9 Jun 2001, Adam wrote:
- removed todo notes from pktcdvd.c and put it into TODO file.
The TODO file currently contains this information: - Currently writing slows down considerably when either a large file or several files are written to a device (keyword is writing more than the buffer mem can handle). At this point the internal pktcdvd "elevator" is not given the opportunity to do proper coalescing of requests, which means we have to go and read those blocks from disc... We already try to work around this problem by bringing in data for several requests before firing them (see the internal buffer pool, and pkt_handle_queue), but the less data we have to bring in the better. This is my theory, I may be completely off track and the cause of the lack of "full" requests lie elsewhere. Increasing FREE_BUFFERS in pktcdvd.h will improve the current situation at the cost of eating more memory (we are currently using 256, which means 256*2048 = 0.5MB of memory). I could not find any references to FREE_BUFFERS in the source. There is a config option called CONFIG_CDROM_PKTCDVD_BUFFERS, but it doesn't seem to be used. Anyway, I think the reason for slow write performance is that we don't try to find data in the page cache when collecting data for a non-full packet. We do look in the buffer cache, but I think looking in the page cache would be much more effective. What's needed is to make the pkt_get_page_hash() function work and to start using it. Unfortunately, I don't know how to do that. -- Peter Österlund peter.osterlund@mailbox.swipnet.se Sköndalsvägen 35 http://home1.swipnet.se/~w-15919 S-128 66 Sköndal +46 8 942647 Sweden
On Sat, 9 Jun 2001, Adam wrote:
packet-0.0.2l-as2, an incremental release to packet-0.0.2l-as
it works (at least should) with kernels 2.4.5 2.4.6-pre1 2.4.6-pre2
I just saw packet-0.0.2l-as3 on your web site and wanted to compile
it with 2.4.5-ac13. Patch applies fine, but SysRq support fails
to compile now.
The (untested) patch below lets you compile without errors.
Arnd <><
--- drivers/char/sysrq.c-2.4.5-ac13-pkt Thu Jun 14 15:13:40 2001
+++ drivers/char/sysrq.c Thu Jun 14 15:19:35 2001
@@ -28,6 +28,8 @@
#include
participants (3)
-
Adam -
Arnd Bergmann -
Peter Osterlund