Re: The advantage of modules?
> Although I haven't been involved for over 8 years, it us unlikely that > the word "SCSI" has been given up as some generic aspirin. SCSI still > means the stuff specified in the 519 Page document copyrighted by > ANSI, called "SMALL COMPUTER SYSTEM INTERFACE - 2", Dated May 20, 1991, > and the first draft released in June of 1986. SCSI nowdays is a message protocol. Its what powers fibrechannel at the high end and ATAPI (IDE) and USB at the low end. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
On Mon, 8 Jan 2001, Dan Hollis wrote: > On Mon, 8 Jan 2001, Russell King wrote: > > Seriously though, you can't depreciate a term for referring to a type of > > bus without providing some other term to describe said bus. > > You need to distinguish between SCSI-the-protocol and > SCSI-the-physical-layer. The term "SCSI" alone is simply too ambiguous to > be really useful anymore. I think you can use term "SCSI-1" or "SCSI-2" > when specicfally meaning SCSI protocol over classic 50 wire layer. > > Saying "SCSI does not support hotplug" is very misleading. > > Right now, the term "SCSI" is more akin to "IP". > > -Dan Err The American National Standard for information Systems, under the American National Standards Institute, ANSI, approved a "Small Computer System Interface" (SCSI) standard on June 23, 1986. There have been many revisions, one of the last, called SCSI-2, was approved on May 20, 1991. I used to sit on the committee. I have some of the original drafts. Although I haven't been involved for over 8 years, it us unlikely that the word "SCSI" has been given up as some generic aspirin. SCSI still means the stuff specified in the 519 Page document copyrighted by ANSI, called "SMALL COMPUTER SYSTEM INTERFACE - 2", Dated May 20, 1991, and the first draft released in June of 1986. As such, you are not supposed to use the word SCSI to mean "control packet interface" or whatever. It is supposed to refer to the hardware and communications specifications (software), defined by the standard. Although nobody is likely to haul is into court, we should not be using SCSI to mean anything else. And, SCSI does not "specify" hot-plug. It's just not covered in the standard. However, you can certainly provide capabilities not covered by a particular standard. It is some implementation details on how SCSI (and other) devices are mounted, connected, disconnected, and controlled that may allow hot-plugging. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
On Mon, 8 Jan 2001, Russell King wrote: > Seriously though, you can't depreciate a term for referring to a type of > bus without providing some other term to describe said bus. You need to distinguish between SCSI-the-protocol and SCSI-the-physical-layer. The term "SCSI" alone is simply too ambiguous to be really useful anymore. I think you can use term "SCSI-1" or "SCSI-2" when specicfally meaning SCSI protocol over classic 50 wire layer. Saying "SCSI does not support hotplug" is very misleading. Right now, the term "SCSI" is more akin to "IP". -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
Dan Hollis writes: > On Mon, 8 Jan 2001, Russell King wrote: > > I don't believe that is what it's trying to say. There have been instances > > in the past where unplugging a SCSI device from a powered on SCSI bus can > > result in blown terminator power fuses and the like. Whether this still > > applies today, I don't know (are active terminators better or worse than > > passive when it comes to this type of thing?) > > The term SCSI is depreciated as purely a physical layer. We talk SCSI over > many different physical layers (1394, usb, ata). Of course many of these > support hot plug natively. And can you please explain how I can attach this USB Zip drive to this 50-wire SCSI bus please? Or would you prefer me to call it a bus? Something with 4 wheels maybe? Maybe we should depreciate the term "bus" as well just to remove that confusion. ;) Seriously though, you can't depreciate a term for referring to a type of bus without providing some other term to describe said bus. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
On Mon, 8 Jan 2001, Russell King wrote: > > so my take is unless you explicitly use hotplug devices (I wasn't), that > > it is much safer to unload the driver, unattach/attach scsi devices, and > > then reload the driver (which will scan the scsi bus for devices), which > > you need modules for. > I don't believe that is what it's trying to say. There have been instances > in the past where unplugging a SCSI device from a powered on SCSI bus can > result in blown terminator power fuses and the like. Whether this still > applies today, I don't know (are active terminators better or worse than > passive when it comes to this type of thing?) The term SCSI is depreciated as purely a physical layer. We talk SCSI over many different physical layers (1394, usb, ata). Of course many of these support hot plug natively. You can get hotplug adapters for ata devices now. Can linux handle them? -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
Michael Meissner writes: > Quoting from drivers/scsi/scsi.c: > > /* >* Usage: echo "scsi add-single-device 0 1 2 3" >/proc/scsi/scsi >* with "0 1 2 3" replaced by your "Host Channel Id Lun". >* Consider this feature BETA. >* CAUTION: This is not for hotplugging your peripherals. As >* SCSI was not designed for this you could damage your >* hardware ! >* However perhaps it is legal to switch on an >* already connected device. It is perhaps not >* guaranteed this device doesn't corrupt an ongoing data transfer. >*/ > > so my take is unless you explicitly use hotplug devices (I wasn't), that > it is much safer to unload the driver, unattach/attach scsi devices, and > then reload the driver (which will scan the scsi bus for devices), which > you need modules for. I don't believe that is what it's trying to say. There have been instances in the past where unplugging a SCSI device from a powered on SCSI bus can result in blown terminator power fuses and the like. Whether this still applies today, I don't know (are active terminators better or worse than passive when it comes to this type of thing?) However, what I do know is the following, and I learnt it the hard way: I once had a machine and other stuff on a 4-way mains connector block that has been used for many years. Unknown to me, the earth wire had become intermittent. I was just about to connect another peripheral which was directly connected to the wall socket to this computer, and I happened to touch the connector body on both the peripheral and the computer. I now know what a shock of >120V feels like. Now, imagine what would happen if you connect a SCSI device, where this condition exists, and the first thing that makes contact is the SCSI databus. Say goodbye to most, if not all devices on that SCSI bus. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
On Mon, Jan 08, 2001 at 07:26:01PM +0100, Ookhoi wrote: > >3) Having drivers as modules means that you can remove them and > >reload them. When I was working in an office, I had one scsi > >controller that was a different brand (Adaptec) than the main scsi > >controller (TekRam), and I hung a disk in a removable chasis on the > >scsi chain in addition to a tape driver and cd-rom. When I was > >about to go home, I would copy all of the data to the disk, unmount > >it, and then unload the scsi device driver. I would take the disk > >out, and reload the scsi device driver to get the tape/cd-rom. I > >would then take the disk to my home computer. I would reverse the > >process when I came in the morning. > > You don't need modules for this to work. Quoting from drivers/scsi/scsi.c: /* * Usage: echo "scsi add-single-device 0 1 2 3" >/proc/scsi/scsi * with "0 1 2 3" replaced by your "Host Channel Id Lun". * Consider this feature BETA. * CAUTION: This is not for hotplugging your peripherals. As * SCSI was not designed for this you could damage your * hardware ! * However perhaps it is legal to switch on an * already connected device. It is perhaps not * guaranteed this device doesn't corrupt an ongoing data transfer. */ so my take is unless you explicitly use hotplug devices (I wasn't), that it is much safer to unload the driver, unattach/attach scsi devices, and then reload the driver (which will scan the scsi bus for devices), which you need modules for. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
Hi Michael, > On Fri, Jan 05, 2001 at 10:50:20PM -0600, Evan Thompson wrote: > > I'd like to know (I know, I'm being slightly off topic, while still > > staying on topic, so I'm on topic...er...yes) if there is any > > advantage, be it memory-wise or architectuarally wise, to use > > modules? > > > > I already know the obvious points of if you are creating a distro > > that it is usually good to make a very modular kernel for those > > wishing not to recompile their kernel, but I was wondering if there > > were any other advantages to using modules vs. making a monolithic > > kernel for a kernel to be used only on one machine (with no other > > hardware support at all)? > > A couple of thoughts: > >1) A full kernel with everything compiled in might not fit on boot >media such as floppies, while modules allows you to not load stuff >that isn't needed to until after the main booting is accomplished. > >2) There are several devices that have multiple drivers (such as >tulip, and old_tulip for example). Which particular driver works >depends on your exact particular hardware. If both of these >drivers are linked into the kernel, whatever the kernel chooses to >initialize first will talk to the device. > >3) Having drivers as modules means that you can remove them and >reload them. When I was working in an office, I had one scsi >controller that was a different brand (Adaptec) than the main scsi >controller (TekRam), and I hung a disk in a removable chasis on the >scsi chain in addition to a tape driver and cd-rom. When I was >about to go home, I would copy all of the data to the disk, unmount >it, and then unload the scsi device driver. I would take the disk >out, and reload the scsi device driver to get the tape/cd-rom. I >would then take the disk to my home computer. I would reverse the >process when I came in the morning. You don't need modules for this to work. Ookhoi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
On Fri, Jan 05, 2001 at 10:50:20PM -0600, Evan Thompson wrote: > I'd like to know (I know, I'm being slightly off topic, while still > staying on topic, so I'm on topic...er...yes) if there is any > advantage, be it memory-wise or architectuarally wise, to use modules? > > I already know the obvious points of if you are creating a distro that > it is usually good to make a very modular kernel for those wishing not > to recompile their kernel, but I was wondering if there were any other > advantages to using modules vs. making a monolithic kernel for a > kernel to be used only on one machine (with no other hardware support > at all)? A couple of thoughts: 1) A full kernel with everything compiled in might not fit on boot media such as floppies, while modules allows you to not load stuff that isn't needed to until after the main booting is accomplished. 2) There are several devices that have multiple drivers (such as tulip, and old_tulip for example). Which particular driver works depends on your exact particular hardware. If both of these drivers are linked into the kernel, whatever the kernel chooses to initialize first will talk to the device. 3) Having drivers as modules means that you can remove them and reload them. When I was working in an office, I had one scsi controller that was a different brand (Adaptec) than the main scsi controller (TekRam), and I hung a disk in a removable chasis on the scsi chain in addition to a tape driver and cd-rom. When I was about to go home, I would copy all of the data to the disk, unmount it, and then unload the scsi device driver. I would take the disk out, and reload the scsi device driver to get the tape/cd-rom. I would then take the disk to my home computer. I would reverse the process when I came in the morning. 4) If you have multiple scsi controllers of different brands, building on into the kernel and the other brand(s) as modules allows you to control which scsi controller is the first controller in terms of where the disks are. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
On Sat, Jan 06, 2001 at 11:02:15AM +0100, J . A . Magallon wrote: > > On 2001.01.06 Drew Bertola wrote: > > My best reasons are... > > > > Development: You don't have to recompile the kernel a billion times > > while working on a driver, you just recompile the module. Also, you > > can debug, unload, fix, recompile, reload a module to add or fix > > pieces of it all (hopefully) without rebooting. > > > > Practical usage: When I take my laptop on the road I use ppp, so I > > load it then. Most of the time I don't need it, so I don't load it. > > > > Usage: I have seen drivers which require params to work, and you can > only give params if the driver is built as a module (ie, > modprobe xx io=0x300 irq=5, etc...) because your hard is not > properly autodetected by the module. For many devices you can specify the parameters at boot time if you use something like lilo to boot. -- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [EMAIL PROTECTED] phone: +1 978-486-9304 Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
On 2001.01.06 Drew Bertola wrote: > My best reasons are... > > Development: You don't have to recompile the kernel a billion times > while working on a driver, you just recompile the module. Also, you > can debug, unload, fix, recompile, reload a module to add or fix > pieces of it all (hopefully) without rebooting. > > Practical usage: When I take my laptop on the road I use ppp, so I > load it then. Most of the time I don't need it, so I don't load it. > Usage: I have seen drivers which require params to work, and you can only give params if the driver is built as a module (ie, modprobe xx io=0x300 irq=5, etc...) because your hard is not properly autodetected by the module. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.0-ac2 #6 SMP Sat Jan 6 01:38:26 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The advantage of modules?
My best reasons are... Development: You don't have to recompile the kernel a billion times while working on a driver, you just recompile the module. Also, you can debug, unload, fix, recompile, reload a module to add or fix pieces of it all (hopefully) without rebooting. Practical usage: When I take my laptop on the road I use ppp, so I load it then. Most of the time I don't need it, so I don't load it. Evan Thompson writes: > I'd like to know (I know, I'm being slightly off topic, while still > staying on topic, so I'm on topic...er...yes) if there is any > advantage, be it memory-wise or architectuarally wise, to use modules? > > I already know the obvious points of if you are creating a distro that > it is usually good to make a very modular kernel for those wishing not > to recompile their kernel, but I was wondering if there were any other > advantages to using modules vs. making a monolithic kernel for a > kernel to be used only on one machine (with no other hardware support > at all)? > > Thanks, and sorry if I'm being slightly off topic... > Kernels are fun! I wish I could learn more! > -- > +--+---+ > | Evan Thompson|POWERED BY:| > | [EMAIL PROTECTED] | Linux cd168990-a 2.4.0-ac2 #1 Fri | > | Freelance Computer Nerd | Jan 5 11:58:30 CST 2001 i686 | > | http://evaner.penguinpowered.com | unknown | > +--+---+ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Drew Bertola | Send a text message to my pager or cell ... | http://jpager.com/Drew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/