Chris your post had little to do with my post, but there are several
things that beg for clarification anyway.

On Fri, 23 Jul 2004 14:19:09 +1200 (NZST)
Christopher Sawtell <[EMAIL PROTECTED]> wrote:
>  
> Here are my ideas. 
> Use the scanmodem program from linmodems.org to identify the hardware, do not 
> trust that the client knows exactly and correctly what all the details are. 
> Use google to verify the PCI id codes. 

all done, 

> Tell the bios that the o/s is not able to do plug and play. 

was already set to not do p&p

> Make sure the kernel and the headers are truely mates for each other. 

sorted

> There have been mistakes made more than once by the distributors. 
> In effect this means getting a known good kernel archive and compiling it 
> yourself.

no it doesn't necessarily. there are no issues with missing or
mismatched symbols like you would expect from a kernel mismatch.

>Remember here that some modem drivers are not yet able to integrate 
> correctly with the 2.6.X kernels.  

I assume David did the research and got the ltmodem driver that works
with 2.6. it obviously compiled cleanly (although I did not do it, it
must have been done on saturday)

>  
> Configure the kernel by hand and ensure that irq sharing is off!! 

which setting is that. my .config for a 2.6 series kernel has the
expression "irq" only once:

[EMAIL PROTECTED] linux $ grep -i irq .config
CONFIG_IDEPCI_SHARE_IRQ=y

which seems to be ide specific. on a 2.4 series:

[EMAIL PROTECTED] linux # grep -i irq .config
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_SERIAL_SHARE_IRQ=y
# CONFIG_SERIAL_DETECT_IRQ is not set

However I am not sure if unconfigured or default options necessarily
appear in .config.

can you be more specific about the setting you say is wrong here. BTW it
is pretty normal for all PCI systems to share interrupts, in my limited
knowledge of PC hardware.

The other point is I am not about to hand patch a kernel to match
whatever it is that Mandrake, or any other distributor want in their
kernel.

> It is sensible to trust knoppix to detect the hardware correctly. It's very 
> good. 
> Compile and install the kernel and modules. 
> Boot device driver and filesystem built-in. Everything else as modules. 
> Compile the modem driver. 
> Install it. 
> Some modem drivers ( slmodem iirc ) are implemented as daemons which will need 
> to be started. ( Probably, the best place to do this is via the /etc/inittab 
> file, because the daemon will be automatically restarted if it dies, but 
> otherwise as an entry into rc.local ) 

well this is NOT an slmodem if you read my OP. But even if it was you
are wrong. The place to start it is from the startup script usually
called /etc/init.d/slmodemd.

>  
> Etch into your memory that the acronym RPM stands for Really Piss-poor Method. 
> That is the reason why most modem drivers are distributed as tar files. 
>  
>  

That is a complete and utter misrepresentation of RPM. The reason many modem
driver source files are distributed as tar files is the same reason that
most software sources are distributed as tar files, to facilitate
getting the source file in one place so that you can run make on it. 

Sometimes the distributor (as in Mandrake etc) or the writer
(linuxant etc) make source rpm's to facilitate compliling the source
against whatever kernel happens to be in place. Source rpm's are
extremely useful as they automate the configure and make procedures. The
rpm philosophy is to include the original sources in pristine condition
in the src.rpm, along with any patches the rpm maintainer wishes to add.
the "instructions" are contained in one file, the .spec file.

Often either the distributor (as in Mandrake etc) or the writer
(linuxant etc) make binary rpm's of the files, but that leads to a
proliferation of rpms as it needs to match the kernel, so when the
distributor upgrades their kernel, someone needs to do a new binary rpm.

There is nothing wrong with rpm in general if you put a decent front end
on it that will sort out dependencies automatically. Enter yum, urpmi,
apt-rpm, yast, etc. 

> --  
> Sincerely etc.  
> Christopher Sawtell  
>   

-- 
Nick Rout <[EMAIL PROTECTED]>

Reply via email to