Programming

thanks. Will try the linux kernel mailing lists.

Regarding the device interfacing, my requirement deals with a set of data transfers, either be in DMA or PIO mode (for older hdds), in the current program (The one which I've written in assembly in DOS), I move the data to a location, fill up necessary details in the ATA Command Packet, send the command to the HDD ( In DMA Mode), the dma controller and HDD will do the rest.

You are right about the ATAPI timeouts and about the way the calls return to the program. I will be waiting at status registers of the drive to check if the call has passed / failed and proceed further. It sometimes can take more time, in order of milliseconds based on the amount of data I am pointing too at the DMA / PIO buffer in the ATA command packet. And I will not be waiting for the timeout there. (The timeout actually would be the HDD's internal read / write call based) and the result is sent as a signal in one of the status registers as a return value for my actual data transfer call.

I referred to that in my query as the read / write timeout. (I guess I am being a little void in stating my requirements and missing out a lot of key requirements / explanations! ).

It was a good start for me to get into discussion on this board with you and others as to refresh lots of things. It really helps to discuss with a geek (i hope i can address you as one!? ) to get things right and straight at times. (well most of the times!). It was a huge relief after burning mid night oil for weeks at various issues (the current issue was/is still one of the major ones). I think I'll soon be active on this board whenever I can (once I complete my current task and get back home!), helping people.

Switching to the latest kernel has any value addition? Say, any version in 2.6.3?? There were some changes related to RAW or O_DIRECT (I could not remember the exactly) with the newer version.

I haven't been following kernel changes, that I don't know.

I still think the timeout is in the drive, though may be configurable on certain drives. But not all drives. I've used Spinrite on some sick drives now and then, and there's some drives it can spot bad sectors quickly on, and some that still do the clunk-and-whine-45-seconds-per-sector dance. Particularly older drives. Maybe configuring that's an ATA extension?

I feel that the implementation is manufacturer and model specific in most of the cases I've seen so far. Also, the revision of ATA specs the drive implements. Older the drive, the longer it takes on certain specific operations (though not necessarily).

I have been composing a knowledge base for internal use, (for the past 6 years) comprising various drives ranging from sizes of few MBs to the TB's in IDE / SATA, SCSI, SAS and FC and believe me, there are some obscure models which say they implement a particular specification (be it ATA or some other spec) Version and revision, but does not work when a version specific command is fired towards them!

It's been a long journey working with the magnetic media and erasure applications and I have seen almost all of the market leaders hands on(including hardware)!!

Your requirements are becoming somewhat clearer. Quite different from your original question.

You can directly manipulate disks using ATA commands from userspace in Linux provided the disk is not mounted. The simpliest utility which does this, and whose source code is available to look at (See TSK sources) , is probably disk_sreset which temporarily removes a disk's HPA.

Thanks for the link. Will look into the sleuth kit's sources.

I don't want to do an ATA transfer, but would like transfer the data at a higher level.

Well, the kernel can't understand your intentions here -- you don't just want unbuffered I/O, you want I/O with no cache at all and subtly altered transfer modes. You might have to interact with the drive other ways than a read() call, or run a custom kernel...

I'm not sure if it can do precisely what you want either, but these days, nearly all Linux block devices act like SCSI, and those that don't are depreciated. With generic SCSI interfaces enabled in the kernel, you can get a corresponding /dev/sg[0-9] for your /dev/sd[a-z]. If I understand their purpose correctly you could use lower-level SCSI commands to control PATA, SATA, USB, and of course actual SCSI drives. That might help you do forensics in a more device-independent way, if that is your goal.

I guess I'm gonna try that. Will update soon. thanks

---------- Post updated 02-24-10 at 11:30 AM ---------- Previous update was 02-23-10 at 08:15 PM ----------

Based on Corona688 suggestion, I have developed the method (using SG calls) to send ATA / SCSI commands to the device directly (almost) same as the (Assembly and DOS) ATA world. Will update soon on the progress.