>Hello Monty, >Good to see you back on this thread. Well, I was back for a little before getting hammered again ;-) >Checked out 'Rubini' and there is a hack called >'filp->private_data (void *)' into which I put the 'users' variable >during a sg_open(). ['users' is held per device and is bumped >for each open() and decremented by each close().] In the same >process I opened the same sg device twice and then interleaved >writes to it and that 'users' variable held in 'private_data' >correctly identified which user space fd was doing the write. >This means the answer to your question is: "Yes, relatively >easily". Oh, goodie goodie. Kernel tracking of commands by fd is definately the proper way to be isolating things. >My 'sg' web page: http://www.netwinder.org/~dougg has been >updated several times in the last 2 weeks and includes an >almost useful test program called sg_dd512 which is a >dd specialization. I also have been looking at Heiko Eissfeldt's >sg extensions (pointed to by my web page). They don't amount >to much more than returning the full error codes (which is not >a bad start). His extensions also have a "lazy" buffer allocation >replacing the original static buffer. This has advantages (eg >multiple users on 1 sg device) and disadvantages (eg write() >could return ENOMEM at some very embarassing time - >during a CD burn, for example). Agreed. >BTW I have several email addresses: this one in the Royal >Bank of Canada (which I may not have for that much longer), >[EMAIL PROTECTED], [EMAIL PROTECTED] and >[EMAIL PROTECTED] . In the "Cc" of your email to me titled >"Re: ATAPI/SG/PG unification? ..." is a >"[EMAIL PROTECTED]". That is _not_ my email address >(although I did try to get it but was told it was in use). Perhaps, >by some strange co-incidence, could that >[EMAIL PROTECTED] also be interested in the Linux "sg" >driver discussion?? Nope, it bounces. But then, that would be too much serendipity to handle. I'd just run away screaming. As a note, I'm mostly interested in the interface involved. Of course, I want the implementation to work too, but I'm worried about getting sucked too far into kernel hacking. I'm way too far behind on the software I've already promised to write... That said, shall I take a look at the BSD interface I missed (does anyone have more information about possible ioctl() limitations, or if the reasons Linux originally moved away from the interface are now obsolete?), then SG, PG, the extentions you've made, etc, and come up with a first rough cut of a unified interface spec? I know damned well I'm going to miss alot of details when I try, so it's important that y'all smack me around around when I miss something. I'm volunteering mainly to keep the ball rolling. Who else should we be pulling in at this point? Monty - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
