sd driver

sd driver

[Aldo Gavioli]

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


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

Re: sd driver

[Arjan van de Ven]

On Mon, 2005-05-23 at 17:39 +0200, 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.

ignoring the previous answer and posting your question three times isn't
going to get your question answered faster.

Re: sd driver

[Kumba]

Arjan van de Ven wrote:
> 
> ignoring the previous answer and posting your question three times isn't
> going to get your question answered faster.
> 

Just out of mild curiosity, when one composes a question after much research, 
and posts it to a mailing list, but gets no response after...almost 2-3 weeks, 
is it considered impolite to re-post or otherwise "bump" the question again? :)


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: sd driver

[randy_dunlap]

On Mon, 23 May 2005 20:49:57 -0400 Kumba wrote:

| Arjan van de Ven wrote:
| > 
| > ignoring the previous answer and posting your question three times isn't
| > going to get your question answered faster.
| > 
| 
| Just out of mild curiosity, when one composes a question after much research, 
| and posts it to a mailing list, but gets no response after...almost 2-3 weeks, 
| is it considered impolite to re-post or otherwise "bump" the question again? :)

No, that's OK, but that's not what happened in this case.
We saw 2 or 3 emails from Aldo in the space of 1-2 days.

---
~Randy

Re: sd driver

[Kumba]

randy_dunlap wrote:
> 
> No, that's OK, but that's not what happened in this case.
> We saw 2 or 3 emails from Aldo in the space of 1-2 days.

I was being somewhat sarcastic in my response, specifically because while I 
considered my question [1] (more like a descriptive problem) lengthy, and 
decently researched, I got no response for the rough length of time mentioned in 
my preceeding response.  Yet, a person who writes a 6-8 line email and provides 
virtually no information about their issue, or environment the issue is occuring 
in, gets a response rather quickly.

As I often like to say, "Go Figure", but that's just the cynic in me tonight.  I 
blame C strings.


[1]: http://marc.theaimsgroup.com/?l=linux-scsi&m=111474736920566&w=2


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: sd driver

[randy_dunlap]

On Mon, 23 May 2005 23:26:56 -0400 Kumba wrote:

| randy_dunlap wrote:
| > 
| > No, that's OK, but that's not what happened in this case.
| > We saw 2 or 3 emails from Aldo in the space of 1-2 days.
| 
| I was being somewhat sarcastic in my response,

Yes, I detected that, but I chose to ignore it.

| specifically because while I 
| considered my question [1] (more like a descriptive problem) lengthy, and 
| decently researched, I got no response for the rough length of time mentioned in 
| my preceeding response.  Yet, a person who writes a 6-8 line email and provides 
| virtually no information about their issue, or environment the issue is occuring 
| in, gets a response rather quickly.
| 
| As I often like to say, "Go Figure", but that's just the cynic in me tonight.  I 
| blame C strings.

Surely.  :)


| [1]: http://marc.theaimsgroup.com/?l=linux-scsi&m=111474736920566&w=2

Good luck.  I can't help with that one.

---
~Randy

sd driver

[Aldo Gavioli]

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


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

Re: sd driver

[Douglas Gilbert]

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

Re: sd driver

[Aldo Gavioli]

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 

Re: sd driver

[Arjan van de Ven]

> We cannot denied to load different drivers than sd for type MOD.

why not? 
> This behaviour will generate other troubles in developper community.

which community?

again I asked you a question which you didn't bother to answer yet:
Did you write your closed module with linux in mind or even specifically
for linux? Because if so it *really* is better for everyone if you could
show code on how to deal with your device instead, so that generic linux
will work with it. (and it also avoids a big mess wrt GPL issues)

Re: sd driver

[Aldo Gavioli]

Arjan,

>>We cannot denied to load different drivers than sd for type MOD.
>>    
>>
>
>why not? 
>  
>
because it seems that if sd driver attach the device as first one, other 
Upper Level Drivers  will not be called anymore from mid layer scsi.
And they will result not attached. Is this my fault or this is the real 
behaviour of kernel 2.6 ?

>>This behaviour will generate other troubles in developper community.
>>    
>>
>
>which community?
>  
>
Anyone is developping SCSI driver to pilot type MOD.

>again I asked you a question which you didn't bother to answer yet:
>Did you write your closed module with linux in mind or even specifically
>for linux? Because if so it *really* is better for everyone if you could
>show code on how to deal with your device instead, so that generic linux
>will work with it. (and it also avoids a big mess wrt GPL issues)
>  
>
Sorry for this. Here is my answer.
We are developping driver to be inserted in a software suite that will 
pilot optical drive with Write Once disk.
We have no problem to publish our driver source code.
In any case we think that could be not interesting  inserting in sd 
driver our private code and in case it will take very long time.
We are thinking about the best solution for this issue.

Thanks
Aldo

>
>
>  
>


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