I think we should get rid of ide-scsi.
Reasons:
1) It's broken.
2) It's unmaintained.
3) It's unneeded.
I'll submit a patch if people agree.
I code, therefore I am
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Alex Davis wrote:
> I think we should get rid of ide-scsi.
>
> Reasons:
> 1) It's broken.
> 2) It's unmaintained.
> 3) It's unneeded.
>
> I'll submit a patch if people agree.
>
> I code, therefore I am
I personally do not agree with this. I worked on at boot disk(floppy) which
contained the kernel and modules to find a cdrom (or usb disk) and use it as
my 2nd stage. If I had to use ide-cd, I would not beable to do my first
stage loader on a single floppy (I support ide and scsi cdroms via sr-mod).
ide-cd.ko is > than sr-mod.ko + ide-scsi.ko
I am aware that scsi_mod.ko is larger than those 3 combined and I still need
it regardless for usb.
My personal vote would be to drop the entire ide subsystem which would thus
drop ide-scsi. The SCSI layer has been a general block device layer for
more than true scsi devices. USB, Firewire, and SATA use the scsi layer.
And as I understand it, libata is starting to handle PATA devices. Once it
can handle PATA fine, the ide code would pretty much be useless.
I am also against the seperate USB block layer, I personally saw no use in
it.
--
Lab tests show that use of micro$oft causes cancer in lab animals
Got Gas???
On Thu, Feb 09, 2006 at 07:36:14PM -0500, Wakko Warner wrote:
>
> I am also against the seperate USB block layer, I personally saw no use in
> it.
What "seperate USB block layer"?
thanks,
greg k-h
On 02/09/2006 09:24 PM, Greg KH wrote:
> On Thu, Feb 09, 2006 at 07:36:14PM -0500, Wakko Warner wrote:
>
>>I am also against the seperate USB block layer, I personally saw no use in
>>it.
>
>
> What "seperate USB block layer"?
>
> thanks,
>
> greg k-h
I assume he means CONFIG_BLK_DEV_UB.
--
Joshua Kwan
--- Wakko Warner <[email protected]> wrote:
> Alex Davis wrote:
> > I think we should get rid of ide-scsi.
> >
> > Reasons:
> > 1) It's broken.
> > 2) It's unmaintained.
> > 3) It's unneeded.
> >
> > I'll submit a patch if people agree.
> >
> > I code, therefore I am
>
> I personally do not agree with this. I worked on at boot disk(floppy) which
> contained the kernel and modules to find a cdrom (or usb disk) and use it as
> my 2nd stage. If I had to use ide-cd, I would not beable to do my first
> stage loader on a single floppy (I support ide and scsi cdroms via sr-mod).
>
> ide-cd.ko is > than sr-mod.ko + ide-scsi.ko
>
> I am aware that scsi_mod.ko is larger than those 3 combined and I still need
> it regardless for usb.
>
> My personal vote would be to drop the entire ide subsystem which would thus
> drop ide-scsi. The SCSI layer has been a general block device layer for
> more than true scsi devices. USB, Firewire, and SATA use the scsi layer.
> And as I understand it, libata is starting to handle PATA devices. Once it
> can handle PATA fine, the ide code would pretty much be useless.
>
> I am also against the seperate USB block layer, I personally saw no use in
> it.
>
> --
> Lab tests show that use of micro$oft causes cancer in lab animals
> Got Gas???
>
Wakko:
Modules can be compressed: On a 2.6.15 kernel doing a 'gzip -9 idecd.ko' reduced its size
from 43616 bytes to 19234 bytes. The only additional step is modifying 'modules.dep' and
changing idecd.ko to idecd.ko.gz. You now have a fully functional ide cdrom driver.
I code, therefore I am
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Alex Davis wrote:
> --- Wakko Warner <[email protected]> wrote:
> > I personally do not agree with this. I worked on at boot disk(floppy) which
> > contained the kernel and modules to find a cdrom (or usb disk) and use it as
> > my 2nd stage. If I had to use ide-cd, I would not beable to do my first
> > stage loader on a single floppy (I support ide and scsi cdroms via sr-mod).
> >
> > ide-cd.ko is > than sr-mod.ko + ide-scsi.ko
> >
> > I am aware that scsi_mod.ko is larger than those 3 combined and I still need
> > it regardless for usb.
> >
> > My personal vote would be to drop the entire ide subsystem which would thus
> > drop ide-scsi. The SCSI layer has been a general block device layer for
> > more than true scsi devices. USB, Firewire, and SATA use the scsi layer.
> > And as I understand it, libata is starting to handle PATA devices. Once it
> > can handle PATA fine, the ide code would pretty much be useless.
> >
> > I am also against the seperate USB block layer, I personally saw no use in
> > it.
> >
> > --
> > Lab tests show that use of micro$oft causes cancer in lab animals
> > Got Gas???
> >
>
> Wakko:
>
> Modules can be compressed: On a 2.6.15 kernel doing a 'gzip -9 idecd.ko' reduced its size
> from 43616 bytes to 19234 bytes. The only additional step is modifying 'modules.dep' and
> changing idecd.ko to idecd.ko.gz. You now have a fully functional ide cdrom driver.
This I did not know. I'm not sure if it will really matter or not. The
initramfs is already gzip -9'd. I have a list of modules that are required
for stage 1 which pulls in the dependancies for those modules. It does
currently fit on a single floppy. I'm using a upx compressed kernel, a gzip
-9'd initramfs, kernel is compiled with -Os and I'm using a -Os compiled
busybox statically compiled with uclibc. When it's all said and done, I
have less than 10kb available on a floppy. I thought it was quite an
acomplishment getting all that one 1 floppy.
--
Lab tests show that use of micro$oft causes cancer in lab animals
Got Gas???
Greg KH wrote:
> On Thu, Feb 09, 2006 at 07:36:14PM -0500, Wakko Warner wrote:
> >
> > I am also against the seperate USB block layer, I personally saw no use in
> > it.
>
> What "seperate USB block layer"?
Maybe not a "block layer", but there was this Under drivers/block devices in
the config:
Low Performance USB Block driver
--
Lab tests show that use of micro$oft causes cancer in lab animals
Got Gas???
On Iau, 2006-02-09 at 16:21 -0800, Alex Davis wrote:
> I think we should get rid of ide-scsi.
>
> Reasons:
> 1) It's broken.
> 2) It's unmaintained.
> 3) It's unneeded.
#1 is half wrong
#2 is half wrong
#3 is totally wrong
There are devices such as multichangers that need it.
Please wait for the longer term cure - killing off drivers/ide 8).
Alan
On Fri, Feb 10, 2006 at 07:11:07AM -0500, Wakko Warner wrote:
> Greg KH wrote:
> > On Thu, Feb 09, 2006 at 07:36:14PM -0500, Wakko Warner wrote:
> > >
> > > I am also against the seperate USB block layer, I personally saw no use in
> > > it.
> >
> > What "seperate USB block layer"?
>
> Maybe not a "block layer", but there was this Under drivers/block devices in
> the config:
> Low Performance USB Block driver
What is your objection to this driver? It fills a real need for people
who do not want the whole scsi stack in their kernels (embedded, memory
constraints, closed systems, etc.), and probably is not even considered
"Low Performance" anymore.
thanks,
greg k-h
Greg KH wrote:
> On Fri, Feb 10, 2006 at 07:11:07AM -0500, Wakko Warner wrote:
> > Greg KH wrote:
> > > What "seperate USB block layer"?
> >
> > Maybe not a "block layer", but there was this Under drivers/block devices in
> > the config:
> > Low Performance USB Block driver
>
> What is your objection to this driver? It fills a real need for people
> who do not want the whole scsi stack in their kernels (embedded, memory
> constraints, closed systems, etc.), and probably is not even considered
> "Low Performance" anymore.
Ok, now this I did not know which is why I personally objected to it. I saw
no reason to have it with usb-storage since both did something similar. Now
that I know what it's purpose is, I don't see a problem with it as far as
availability to the ones who are low memory, embedded, etc, but I won't need
it myself. I normally use systtems with scsi controllers and need the full
scsi layer.
If/When libata takes over ide in general, how many of these machine will
then require the scsi layer? I would think all systems would except ones
without internal disks (non-usb/firewire).
I do appreciate the info, thanks.
--
Lab tests show that use of micro$oft causes cancer in lab animals
Got Gas???
On Gwe, 2006-02-10 at 12:31 -0500, Wakko Warner wrote:
> If/When libata takes over ide in general, how many of these machine will
> then require the scsi layer? I would think all systems would except ones
> without internal disks (non-usb/firewire).
You'll want libata (but not eventually all of the scsi layer) for just
about anything at that point. On the bright side you won't have scsi
loaded for your USB devices and drivers/ide loaded for your IDE disks so
for most cases I suspect it will be neutral or save memory.
If you are really tighht on memory and just using CF then its probably
worth writing a simple CF driver for embedded use. Its probably a matter
of 10K of code if that for the subset in question.
On Thu, 9 Feb 2006 16:21:48 -0800 (PST), Alex Davis <[email protected]> wrote:
> I think we should get rid of ide-scsi.
>
> Reasons:
> 1) It's broken.
> 2) It's unmaintained.
> 3) It's unneeded.
How are you going to drive IDE tapes without it? The ide-tape driver is
many times worse.
-- Pete
Alex Davis wrote:
> I think we should get rid of ide-scsi.
>
> Reasons:
> 1) It's broken.
> 2) It's unmaintained.
> 3) It's unneeded.
>
> I'll submit a patch if people agree.
People don't agree, could we not have another war like cdrecord? Please?
Go back and read the old posts, particularly discussing tape, MO drives,
and some ide-floppy devices.
It's there, it's maintained as needed, and it works far better than the
alternatives for some devices.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979