I am a noob using Ubuntu server 12.04.5 LTS. There is a need for me to access a SCSI device with logical unit number(LUN) more than 255.According to my knowledge we can't see SCSI devices with lun more than 255. I heard, there is flat space addressing mode for lun which supports lun more than 255. Can I access the volumes(SCSI device) using flat space addressing in Ubuntu? If it is, how?
Please reply if you need further info and excuse me if I made any mistakes in my question.
Related
SR-IOV lets PCIe devices expose a single physical function and multiple virtual functions. How does the kernel detect that a device supports virtual functions? Is it a part of the PCIe configuration registers? Where in the kernel are devices tested for how many functions they export?
EDIT: I'm looking for a line of code (or a file) in the kernel source that inspects a PCIe device in order to determine how many virtual functions it exports. I'd also settle for a link to the appropriate standard that lays out what information a device needs to send to the host in order to report that it supports multiple virtual functions.
An SR-IOV capable device defines the SR-IOV Capability (extended capability ID 10h).
This is specified in chapter 9 of the PCI Express Base specification revision 4.0. I'm not sure whether you can find a free copy online; you may need to be a PCI-SIG member.
In the Linux kernel, look for PCI_EXT_CAP_ID_SRIOV and PCI_SRIOV_TOTAL_VF in drivers/pci/iov.c.
Windows 7
C Programming
Visual C++ 2008 (in a VMWare)
I'd like to send some ATA commands (IDENTIFY DEVICE, READ NATIVE MAX ADDRESS, SET MAX ADDRESS) with DeviceIOControl to a USB hard drive. Therefore I have some questions.
As I understood, USBSTOR cannot handle ATA-commands directly (with IOCTL_ATA_PASS_THROUGH). I tried this and it worked with the native IDE hard drive but not with USB.
Is it correct that applications send SCSI-commands to the device and they are forwarded to the device? So I need to create a SCSI command with the respective ATA command encapsulated?
With what dwIoControlCode can I do that? I tried it with IOCTL_SCSI_MINIPORT but the error was ERROR_NOT_SUPPORTED. Could it work with minport? Is miniport still up to date?
Look at this link:
http://www.mombu.com/microsoft/windows-programmer-nt-kernel-mode/t-howto-send-ata-spec-command-to-usb-hdd-1646752.html
Q: howto send ATA spec. command to USB HDD?
A: You are limited to whatever the USB->ATA tailgate (bridge) chip supports.
If you control the bridge, you can implement whatever you want. If you
don't, you'll have to ask the bridge vendor to reveal what they do support.
See my replies in the thread on 1394->ATA on NTDEV for more information.
Q: Once more question: whether probably to get access to everyone disk
in SCSI RAID?
A: No.
You can only send SCSI commands to the bridge/enclosure at the end of the USB
cable. How they are translated to ATA commands - is not under your control.
I assume El Cheapo enclosures to only translate the essential SCSI commands. In
this case, you will only have 1) SCSI INQUIRY emulated by ATA IDENTIFY 2) SCSI
READ CAPACITY emulated by ATA IDENTIFY 2) READ and WRITE 3) VERIFY.
And that's all. In this case, you will have zero chances sending any
non-trivial ATA commands, since the USB-to-ATA bridge on other side provides no
ways of doing such.
I'm evaluating to port a device driver I wrote several years ago from 32 to 64 bits. The physical device is a 32-bit PCI card. That is, the device is 32 bits but I need to access it from Win7x64. The device presents some registers to the Windows world and then performs heavy bus master data transferring into a chunk of driver-allocated memory.
I've read in the Microsoft documentation that you can signal whether the driver supports 64-bit DMA or not. If it doesn't, then the DMA is double buffered. However, I'm not sure if this is the case. My driver would/could be a full 64-bit one, so it could support 64-bit addresses in the processor address space, but the actual physical device WON'T support it. In fact, the device BARs must be mapped under 4 GB and the device must get a PC RAM address to perform bus master below 4 GB. Does this mean that my driver will go through double buffering always? This is a very performance-sensitive process and the double buffering could prevent the whole system from working.
Of course, designing a new 64-bit PCI (or PCI-E) board is out of question.
Anybody could give me some resources for this process (apart from MS pages)?
Thanks a lot!
This is an old post, I hope the answer is still relevant...
There are two parts here, PCI target and PCI master access.
PCI target access: The driver maps PCI BARs to 64bit virtual address space and the driver just reads/writes through a pointer.
PCI master access: You need to create a DmaAdapter object by calling IoGetDmaAdapter(). When creating, you also describe your device is a 32bit (see DEVICE_DESCRIPTION parameter). Then you call DmaAdapter::AllocateCommonBuffer() method to allocate a contiguous DMA buffer in PC RAM.
I am not sure about double-buffering though. From my experience, double-buffering is not used, instead, DmaAdapter::AllocateCommonBuffer() simply fails if cannot allocate a buffer that satisfies the DEVICE_DESCRIPTION (in your case - 32bit dma addressing).
There's no problem writing a 64-bit driver for a device only capable of 32-bit PCI addressing. As Alexey pointed out, the DMA adapter object you create specifies the HW addressing capabilities of your device. As you allocate DMA buffers, the OS takes this into account and will make sure to allocate these within your HW's accessible region. Linux drivers behave similar, where your driver must supply a DMA address mask to associate with your device that DMA functions used later will refer to.
The performance hit you could run into is if your application allocates a buffer that you need to DMA to/from. This buffer could be scattered all throughout memory, with pages in memory above 4G. If your driver plans to DMA to these, it will need to lock the buffer pages in RAM during the DMA and build an SGL for your DMA engine based on the page locations. The problem is, for those pages above 4G, the OS would then have to copy/move them to pages under 4G so that your DMA engine is able to access them. That is where the potential performance hit is.
Part1:
To the linux/unix experts out there, Could you please help me understanding about device drivers. As i understood, a driver is a piece of code that directly interacts with hardware and exposes some apis to access the device. My question is where does this piece of code runs, User space or Kernel space?
I know that code that is executed in kernel space has some extra privileges like accessing any memory location(pls correct if i'm wrong). If we install a third party driver and if it runs in kernel space, wouldn't this be harmful for the whole system? How any OS handles this?
Part2:
Lets take an example of USB device(camera, keyboard..), How the system recognizes these devices? how does the system know which driver to install? How does the driver know the address of the device to read and write the data?
(if this is too big to answer here, pls provide links of some good documentation or tutorials.., I've tried and couldn't find answers for these. pls help)
Part 1
On linux, drivers run in kernel space. And yes, as you state there a significant security implications to this. Most exceptions in drivers will take down the kernel, potentially corrupt kernel memory (with all manner of consequences). Buggy drivers also have an impact on system security, and malicious drivers can do absolutely anything they want.
A trend seen on MacOSX and Window NT kernels is user-space drivers. Microsoft has for some time been pushing the Windows Userspace Driver Framework, and MacOSX has long provided user-space APIs for Firewire and USB drivers, and class-compliant drivers for many USB peripherals. it is quite unusual to install 3rd party kernel-mode device drivers on MacOSX.
Arguably, the bad reputation Windows used to have for kernel panics can be attributed to the (often poor quality) kernel mode drivers that came with just about every mobile phone, camera and printer.
Linux graphics drivers are pretty much all implemented in user-space with a minimal kernel-resident portion, and Fuse allows the implementation of filing systems in user-space.
Part 2
USB, Firewire, MCI (and also PCI-e) all have enumeration mechanisms through which a bus driver can match the device to a driver. In practice this means that all devices expose metadata describing what they are.
Contained within the metadata is a DeviceID, VendorID and a description of functions the device provides and associated ClassIDs. ClassIDs facilitate generic Class Drivers.
Conceptually, the operating system will attempt to find a driver that specifically supports the VendorID and DeviceID, and then fall back to one that supports the ClassID(s).
Matching devices to drivers is a core concept at the heart of the Linux Device Model, and exact matching criteria used for matching is match() function in the specific bus driver.
Once device drivers are bound to a device, it uses the bus-driver (or addressing information given by it) to perform read and writes. In the case of PCI and Firewire, this is a memory mapped IO address. For USB it bus addressing information.
The Linux Documentation tree provides some insight into the design of the Linux Device Model, but isn't really entry-level reading.
I'd also recommend reading Linux Device Driver (3rd Edition)
I am trying to read/write usb hard drives and flash drives for a DOS application.
I read EDD spec. and it mentions that function Int13(Fn = 48h) can be used to get interface path and device path for a particular disk drive. This also includes usb interface and ata interface.
Now this function also returns a Device Parameter Table Extension (DPTE) table that gives I/O addresses via which a software bypassing Int13h can use to read/write the device. But this table is only for ATA afaik.
I wanna read/write to usb disk/pen drives w/o using Int 13h. Is it possible?
Actually it is a disk I/O sensitive application in protected mode. So using Int13h would involve heavy penalty in terms of performance, due to mode switching. So, I am trying to avoid using Int13h.
Does bios initalizes usb drives to appear as ATA drives too. If so, then I can use DPTE to get the I/O base addresses of the command block and control block and then access the usb drives just like ATA drives. Am I right?
Thanks
This particular issue has been discussed at length among the FreeDOS community. The best guide to the whole issue is the FreeDOS technote "USB with DOS"