Re: sd driver

[Aldo Gavioli <aldo.gavioli@netstorage.it>]

Gilbert,
thanks for your answer.
I'm thinking regarding your ideas which could be the best.
In any case I think that this behaviour is a malfunction of kernel 2.6.
We cannot denied to load different drivers than sd for type MOD.
This behaviour will generate other troubles in developper community.
Aldo

> Aldo Gavioli wrote:
>
>> Hello All,
>>
>> Hello All,
>> I'm trying to attach one proprietary SCSI driver for optical disk on 
>> kernel 2.6.
>> I noted that if sd attach the same device before, my driver will 
>> never be called in the probe function. How can I by-pass this 
>> situation ?
>> If anyone can help me I appreciate very much.
>
>
> Aldo,
> Upper Level Drivers (ULDs of which sd is one) discriminate
> on the basis of the peripheral device type returned by an
> INQUIRY. Currently sd_probe() takes control of TYPE_DISK
> (pdt=0x0) and TYPE_MOD (pdt=0x7 "Optical memory device")
> and will soon take control of TYPE_RBC.
>
> If the class of devices you are interested in is TYPE_MOD
> then (at least for testing) just comment out that bit of
> code in sd_probe().
>
> The st and osst (tape ULDs) co-operate to do a finer
> grain division of labour (see their respective *_probe()
> functions). These ULDs show you one way of solving the
> problem. Another way would be a kernel/module option
> to sd (and possibly other ULDs) telling it to leave
> device <h,c,t,l> (or better some world wide unique
> identifier) alone.
>
>
> As for Arjan's comment about extending sd to cope with
> your class of devices, recent experience with RBC devices
> indicates that such a move may not add to the coherency
> of the sd driver.
>
> Doug Gilbert
>
>
>
>
>
>


-- 
Aldo Gavioli
Product Manager
NetStorage Software s.r.l
Viale Europa,74 - 20090 Cusago (Milan) Italy - Web: www.netstorage.it