pkt_get_disc_info in pktcdcd-2.6
Hi Peter: What was the problem made you "add code for sending generic packet commands without relying on cdrom_device_ops" as you noted in changelog for packet-2.5.44? My interest in this is that when I tried to backport some 2.6 cdrom changes/fixes for my personal 2.4-tree (especially the csets 1.1975 "cdrom get_last_written fixup", and on top of that, 1.2087 "cdrom signedness range fixes") pktcdvd broke. My primary suspect for this is the return changes in the cdrom_get_di function, hence the $SUBJECT; will investigate it more. But this change in kernel is far much later than your change in pktcdvd-2.5/2.6. So, can you explain? Regards, Ozkan Sezer
On Fri, 29 Oct 2004, O.Sezer wrote:
Hi Peter:
What was the problem made you "add code for sending generic packet commands without relying on cdrom_device_ops" as you noted in changelog for packet-2.5.44? My interest in this is that when I tried to backport some 2.6 cdrom changes/fixes for my personal 2.4-tree (especially the csets 1.1975 "cdrom get_last_written fixup", and on top of that, 1.2087 "cdrom signedness range fixes") pktcdvd broke. My primary suspect for this is the return changes in the cdrom_get_di function, hence the $SUBJECT; will investigate it more. But this change in kernel is far much later than your change in pktcdvd-2.5/2.6. So, can you explain?
It was because cdrom_device_ops became private to the cdrom driver, so the packet writing driver couldn't access it. http://lists.suse.com/archive/packet-writing/2002-Oct/0045.html -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
Peter Osterlund wrote:
On Fri, 29 Oct 2004, O.Sezer wrote:
Hi Peter:
What was the problem made you "add code for sending generic packet commands without relying on cdrom_device_ops" as you noted in changelog for packet-2.5.44? My interest in this is that when I tried to backport some 2.6 cdrom changes/fixes for my personal 2.4-tree (especially the csets 1.1975 "cdrom get_last_written fixup", and on top of that, 1.2087 "cdrom signedness range fixes") pktcdvd broke. My primary suspect for this is the return changes in the cdrom_get_di function, hence the $SUBJECT; will investigate it more. But this change in kernel is far much later than your change in pktcdvd-2.5/2.6. So, can you explain?
It was because cdrom_device_ops became private to the cdrom driver, so the packet writing driver couldn't access it.
http://lists.suse.com/archive/packet-writing/2002-Oct/0045.html
OK then, what is the difference between __cdrom_get_di() of 2.4 and cdrom_get_disc_info() of 2.6 in terms of their return codes? Is cdo->generic_packet(cdi, &cgc) supposed to return success/fail (which you use for that purpose in pktcdvd-2.4 afaics) or the buflen? (Asking this in relation to 2.6's cset-1.1975 that I mentioned above). Thanks in advance for the patience ;) Ozkan
On Fri, 29 Oct 2004, O.Sezer wrote:
Peter Osterlund wrote:
On Fri, 29 Oct 2004, O.Sezer wrote:
What was the problem made you "add code for sending generic packet commands without relying on cdrom_device_ops" as you noted in changelog for packet-2.5.44? My interest in this is that when I tried to backport some 2.6 cdrom changes/fixes for my personal 2.4-tree (especially the csets 1.1975 "cdrom get_last_written fixup", and on top of that, 1.2087 "cdrom signedness range fixes") pktcdvd broke. My primary suspect for this is the return changes in the cdrom_get_di function, hence the $SUBJECT; will investigate it more. But this change in kernel is far much later than your change in pktcdvd-2.5/2.6. So, can you explain?
It was because cdrom_device_ops became private to the cdrom driver, so the packet writing driver couldn't access it.
http://lists.suse.com/archive/packet-writing/2002-Oct/0045.html
OK then, what is the difference between __cdrom_get_di() of 2.4 and cdrom_get_disc_info() of 2.6 in terms of their return codes? Is cdo->generic_packet(cdi, &cgc) supposed to return success/fail (which you use for that purpose in pktcdvd-2.4 afaics) or the buflen?
For 2.4.27 it returns success/failure. I don't know what the 2.6 version returns since the packet driver doesn't use that function.
(Asking this in relation to 2.6's cset-1.1975 that I mentioned above).
Do you have a link to that change? What I found on bkbits doesn't seem to be the right one: http://linus.bkbits.net:8080/linux-2.5/cset@41544f5dZGiqMpiRnFfcSpgz79dusQ?nav=index.html|ChangeSet@-1d -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
Peter Osterlund wrote:
On Fri, 29 Oct 2004, O.Sezer wrote:
Peter Osterlund wrote:
On Fri, 29 Oct 2004, O.Sezer wrote:
What was the problem made you "add code for sending generic packet commands without relying on cdrom_device_ops" as you noted in changelog for packet-2.5.44? My interest in this is that when I tried to backport some 2.6 cdrom changes/fixes for my personal 2.4-tree (especially the csets 1.1975 "cdrom get_last_written fixup", and on top of that, 1.2087 "cdrom signedness range fixes") pktcdvd broke. My primary suspect for this is the return changes in the cdrom_get_di function, hence the $SUBJECT; will investigate it more. But this change in kernel is far much later than your change in pktcdvd-2.5/2.6. So, can you explain?
It was because cdrom_device_ops became private to the cdrom driver, so the packet writing driver couldn't access it.
http://lists.suse.com/archive/packet-writing/2002-Oct/0045.html
OK then, what is the difference between __cdrom_get_di() of 2.4 and cdrom_get_disc_info() of 2.6 in terms of their return codes? Is cdo->generic_packet(cdi, &cgc) supposed to return success/fail (which you use for that purpose in pktcdvd-2.4 afaics) or the buflen?
For 2.4.27 it returns success/failure. I don't know what the 2.6 version returns since the packet driver doesn't use that function.
(Asking this in relation to 2.6's cset-1.1975 that I mentioned above).
Do you have a link to that change? What I found on bkbits doesn't seem to be the right one:
Here: http://marc.theaimsgroup.com/?l=bk-commits-head&m=109330228416908&w=2 And then a fix by Jens: http://marc.theaimsgroup.com/?l=bk-commits-head&m=109466412205112&w=2 Ozkan
participants (2)
-
O.Sezer -
Peter Osterlund