* UIO Kernel Driver with Buildroot and QEMU
@ 2015-10-20 15:58 Kenneth Adam Miller
2015-10-20 20:29 ` Kenneth Adam Miller
2015-10-20 22:54 ` Greg KH
0 siblings, 2 replies; 10+ messages in thread
From: Kenneth Adam Miller @ 2015-10-20 15:58 UTC (permalink / raw)
To: kernelnewbies
So I'm building a uio kernel driver with buildroot, and I've gotten the
driver to compile, installed it and can insmod it in the final buildroot
target after booting the image with QEMU.
I'm on linux kernel version 3.14, and I followed the guide here:
https://www.kernel.org/doc/htmldocs/uio-howto/userspace_driver.html
And it describes the location on where the device file that should be
opened by userland code as either one of two locations:
/dev/uioX, with X being a number
or /sys/class/uio/uioX
But the each of following returns nothing:
ls /dev/uio*
ls /sys/class/uio/
After I compile the uio example that is provided in the linux source at
source/drivers/uio/uio.c and uio_dmem_genirq.c, and insmod them, I do
modprobe uio and modprobe uio_dmem_genirq and each of those return nothing.
However, I do see that /sys/modules/uio and /sys/modules/uio_dmem_genirq
What am I doing wrong? Or where are the respective device files that I'm
supposed to use in my userland driver process?
int fd = open("where is it!!?");
mmap(...., fd,..);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151020/0b4365c9/attachment.html
^ permalink raw reply [flat|nested] 10+ messages in thread* UIO Kernel Driver with Buildroot and QEMU 2015-10-20 15:58 UIO Kernel Driver with Buildroot and QEMU Kenneth Adam Miller @ 2015-10-20 20:29 ` Kenneth Adam Miller 2015-10-20 21:56 ` Mandeep Sandhu 2015-10-20 22:54 ` Greg KH 1 sibling, 1 reply; 10+ messages in thread From: Kenneth Adam Miller @ 2015-10-20 20:29 UTC (permalink / raw) To: kernelnewbies Am I missing something? Are those drivers, uio, and uio_dmem_genirq not supposed to created device files in the linux VFS, either /dev or some subfolder /sys? I am using mdev ( http://buildroot.org/downloads/manual/manual.html#_dev_management), I can see the tty devices in /dev, so I know that the devices are being recognized by the kernel. In addition, insmod'ing the same device more than once gives an error where the kernel says that the file already exists. I considered the possibility that these .c files are in fact skeleton files, where users are supposed to create their own uio driver and rely on the services or functions that these provide. But it doesn't explicitly say that anywhere in the guide that I read; if this were the case, why wouldn't it? On Tue, Oct 20, 2015 at 11:58 AM, Kenneth Adam Miller < kennethadammiller@gmail.com> wrote: > So I'm building a uio kernel driver with buildroot, and I've gotten the > driver to compile, installed it and can insmod it in the final buildroot > target after booting the image with QEMU. > > I'm on linux kernel version 3.14, and I followed the guide here: > > https://www.kernel.org/doc/htmldocs/uio-howto/userspace_driver.html > > And it describes the location on where the device file that should be > opened by userland code as either one of two locations: > > /dev/uioX, with X being a number > > or /sys/class/uio/uioX > > But the each of following returns nothing: > > ls /dev/uio* > ls /sys/class/uio/ > > After I compile the uio example that is provided in the linux source at > source/drivers/uio/uio.c and uio_dmem_genirq.c, and insmod them, I do > modprobe uio and modprobe uio_dmem_genirq and each of those return nothing. > However, I do see that /sys/modules/uio and /sys/modules/uio_dmem_genirq > > > What am I doing wrong? Or where are the respective device files that I'm > supposed to use in my userland driver process? > > int fd = open("where is it!!?"); > mmap(...., fd,..); > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151020/c952c659/attachment.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* UIO Kernel Driver with Buildroot and QEMU 2015-10-20 20:29 ` Kenneth Adam Miller @ 2015-10-20 21:56 ` Mandeep Sandhu 2015-10-20 22:55 ` Kenneth Adam Miller 0 siblings, 1 reply; 10+ messages in thread From: Mandeep Sandhu @ 2015-10-20 21:56 UTC (permalink / raw) To: kernelnewbies >> I'm on linux kernel version 3.14, and I followed the guide here: >> >> https://www.kernel.org/doc/htmldocs/uio-howto/userspace_driver.html >> >> And it describes the location on where the device file that should be >> opened by userland code as either one of two locations: >> >> /dev/uioX, with X being a number >> >> or /sys/class/uio/uioX >> >> But the each of following returns nothing: >> >> ls /dev/uio* >> ls /sys/class/uio/ >> >> After I compile the uio example that is provided in the linux source at >> source/drivers/uio/uio.c and uio_dmem_genirq.c, and insmod them, I do >> modprobe uio and modprobe uio_dmem_genirq and each of those return nothing. >> However, I do see that /sys/modules/uio and /sys/modules/uio_dmem_genirq Have a look at this sample driver I wrote sometime back to trigger a UIO issue: https://github.com/mandeepsandhu/uio-hotplug-test I have not had the time to look at where it differs from your implemntation, but I'll leave that to you to figure out :) This create the /devuioX device file which the userspace code is opening. HTH, -mandeep >> >> >> What am I doing wrong? Or where are the respective device files that I'm >> supposed to use in my userland driver process? >> >> int fd = open("where is it!!?"); >> mmap(...., fd,..); > > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ^ permalink raw reply [flat|nested] 10+ messages in thread
* UIO Kernel Driver with Buildroot and QEMU 2015-10-20 21:56 ` Mandeep Sandhu @ 2015-10-20 22:55 ` Kenneth Adam Miller 0 siblings, 0 replies; 10+ messages in thread From: Kenneth Adam Miller @ 2015-10-20 22:55 UTC (permalink / raw) To: kernelnewbies Thanks! To anyone else that might know the answer thanks also (in advance) :D On Tue, Oct 20, 2015 at 5:56 PM, Mandeep Sandhu <mandeepsandhu.chd@gmail.com > wrote: > >> I'm on linux kernel version 3.14, and I followed the guide here: > >> > >> https://www.kernel.org/doc/htmldocs/uio-howto/userspace_driver.html > >> > >> And it describes the location on where the device file that should be > >> opened by userland code as either one of two locations: > >> > >> /dev/uioX, with X being a number > >> > >> or /sys/class/uio/uioX > >> > >> But the each of following returns nothing: > >> > >> ls /dev/uio* > >> ls /sys/class/uio/ > >> > >> After I compile the uio example that is provided in the linux source at > >> source/drivers/uio/uio.c and uio_dmem_genirq.c, and insmod them, I do > >> modprobe uio and modprobe uio_dmem_genirq and each of those return > nothing. > >> However, I do see that /sys/modules/uio and /sys/modules/uio_dmem_genirq > > Have a look at this sample driver I wrote sometime back to trigger a UIO > issue: > > https://github.com/mandeepsandhu/uio-hotplug-test > > I have not had the time to look at where it differs from your > implemntation, but I'll leave that to you to figure out :) > > This create the /devuioX device file which the userspace code is opening. > > HTH, > -mandeep > > > >> > >> > >> What am I doing wrong? Or where are the respective device files that I'm > >> supposed to use in my userland driver process? > >> > >> int fd = open("where is it!!?"); > >> mmap(...., fd,..); > > > > > > > > _______________________________________________ > > Kernelnewbies mailing list > > Kernelnewbies at kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151020/66541303/attachment.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* UIO Kernel Driver with Buildroot and QEMU 2015-10-20 15:58 UIO Kernel Driver with Buildroot and QEMU Kenneth Adam Miller 2015-10-20 20:29 ` Kenneth Adam Miller @ 2015-10-20 22:54 ` Greg KH 2015-10-20 23:40 ` Kenneth Adam Miller 1 sibling, 1 reply; 10+ messages in thread From: Greg KH @ 2015-10-20 22:54 UTC (permalink / raw) To: kernelnewbies On Tue, Oct 20, 2015 at 11:58:21AM -0400, Kenneth Adam Miller wrote: > So I'm building a uio kernel driver with buildroot, and I've gotten the driver > to compile, installed it and can insmod it in the final buildroot target after > booting the image with QEMU. > > I'm on linux kernel version 3.14, and I followed the guide here: > > https://www.kernel.org/doc/htmldocs/uio-howto/userspace_driver.html > > And it describes the location on where the device file that should be opened by > userland code as either one of two locations: > > /dev/uioX, with X being a number > > or /sys/class/uio/uioX > > But the each of following returns nothing: > > ls /dev/uio* > ls /sys/class/uio/ > > After I compile the uio example that is provided in the linux source at source/ > drivers/uio/uio.c and uio_dmem_genirq.c, and insmod them, I do modprobe uio and > modprobe uio_dmem_genirq and each of those return nothing. However, I do see > that /sys/modules/uio and /sys/modules/uio_dmem_genirq? uio.ko is the uio "core", you need a uio driver in order to actually use it. uio_dmem_genirq is a uio driver, have you added the needed device tree entries to have it actually create a device for you? Without them, this driver can not find any hardware to bind to, and as such, no device node will ever be created. I would suggest reading the UIO documentation, it should explain all of this for you already. If not, specific questions are always gladly answered. thanks, greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* UIO Kernel Driver with Buildroot and QEMU 2015-10-20 22:54 ` Greg KH @ 2015-10-20 23:40 ` Kenneth Adam Miller 2015-10-21 0:17 ` Greg KH 0 siblings, 1 reply; 10+ messages in thread From: Kenneth Adam Miller @ 2015-10-20 23:40 UTC (permalink / raw) To: kernelnewbies On Tue, Oct 20, 2015 at 6:54 PM, Greg KH <greg@kroah.com> wrote: > On Tue, Oct 20, 2015 at 11:58:21AM -0400, Kenneth Adam Miller wrote: > > So I'm building a uio kernel driver with buildroot, and I've gotten the > driver > > to compile, installed it and can insmod it in the final buildroot target > after > > booting the image with QEMU. > > > > I'm on linux kernel version 3.14, and I followed the guide here: > > > > https://www.kernel.org/doc/htmldocs/uio-howto/userspace_driver.html > > > > And it describes the location on where the device file that should be > opened by > > userland code as either one of two locations: > > > > /dev/uioX, with X being a number > > > > or /sys/class/uio/uioX > > > > But the each of following returns nothing: > > > > ls /dev/uio* > > ls /sys/class/uio/ > > > > After I compile the uio example that is provided in the linux source at > source/ > > drivers/uio/uio.c and uio_dmem_genirq.c, and insmod them, I do modprobe > uio and > > modprobe uio_dmem_genirq and each of those return nothing. However, I do > see > > that /sys/modules/uio and /sys/modules/uio_dmem_genirq > > uio.ko is the uio "core", you need a uio driver in order to actually use > it. > > uio_dmem_genirq is a uio driver, have you added the needed device tree > entries to have it actually create a device for you? Without them, this > driver can not find any hardware to bind to, and as such, no device node > will ever be created. > I didn't know about that. How do I do that? I'm using buildroot; I guess there's something missing in menuconfig or linux-menuconfig. > > I would suggest reading the UIO documentation, it should explain all of > this for you already. If not, specific questions are always gladly > answered. > The one that I linked? I read that repeatedly. What other documentation is there to read? I also read from Essential Linux Device Drivers, and none of them explained that. There has to be something I'm missing. Thanks a lot! > > thanks, > > greg k-h > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151020/863295bf/attachment-0001.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* UIO Kernel Driver with Buildroot and QEMU 2015-10-20 23:40 ` Kenneth Adam Miller @ 2015-10-21 0:17 ` Greg KH 2015-10-21 0:28 ` Kenneth Adam Miller 0 siblings, 1 reply; 10+ messages in thread From: Greg KH @ 2015-10-21 0:17 UTC (permalink / raw) To: kernelnewbies On Tue, Oct 20, 2015 at 07:40:37PM -0400, Kenneth Adam Miller wrote: > > On Tue, Oct 20, 2015 at 6:54 PM, Greg KH <greg@kroah.com> wrote: > > On Tue, Oct 20, 2015 at 11:58:21AM -0400, Kenneth Adam Miller wrote: > > So I'm building a uio kernel driver with buildroot, and I've gotten the > driver > > to compile, installed it and can insmod it in the final buildroot target > after > > booting the image with QEMU. > > > > I'm on linux kernel version 3.14, and I followed the guide here: > > > > https://www.kernel.org/doc/htmldocs/uio-howto/userspace_driver.html > > > > And it describes the location on where the device file that should be > opened by > > userland code as either one of two locations: > > > > /dev/uioX, with X being a number > > > > or /sys/class/uio/uioX > > > > But the each of following returns nothing: > > > > ls /dev/uio* > > ls /sys/class/uio/ > > > > After I compile the uio example that is provided in the linux source at > source/ > > drivers/uio/uio.c and uio_dmem_genirq.c, and insmod them, I do modprobe > uio and > > modprobe uio_dmem_genirq and each of those return nothing. However, I do > see > > that /sys/modules/uio and /sys/modules/uio_dmem_genirq? > > uio.ko is the uio "core", you need a uio driver in order to actually use > it. > > uio_dmem_genirq is a uio driver, have you added the needed device tree > entries to have it actually create a device for you?? Without them, this > driver can not find any hardware to bind to, and as such, no device node > will ever be created. > > > I didn't know about that. How do I do that? I'm using buildroot; I guess > there's something missing in menuconfig or linux-menuconfig. Um, no, device tree doesn't have anything to do with buildroot, other than the fact that you need such a thing for your platform to work properly. > I would suggest reading the UIO documentation, it should explain all of > this for you already.? If not, specific questions are always gladly > answered. > > > The one that I linked? I read that repeatedly. What other documentation is > there to read? I also read from Essential Linux Device Drivers, and none of > them explained that. There has to be something I'm missing.? Step back, what exactly are you trying to do here that you think UIO is the answer? Where is the uio driver that you want to run for your hardware platform? UIO is a _very_ hardware-specific solution to a _very_ specific problem that people have, are you sure it's what you need? thanks, greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* UIO Kernel Driver with Buildroot and QEMU 2015-10-21 0:17 ` Greg KH @ 2015-10-21 0:28 ` Kenneth Adam Miller 2015-10-21 0:43 ` Greg KH 0 siblings, 1 reply; 10+ messages in thread From: Kenneth Adam Miller @ 2015-10-21 0:28 UTC (permalink / raw) To: kernelnewbies On Tue, Oct 20, 2015 at 8:17 PM, Greg KH <greg@kroah.com> wrote: > On Tue, Oct 20, 2015 at 07:40:37PM -0400, Kenneth Adam Miller wrote: > > > > On Tue, Oct 20, 2015 at 6:54 PM, Greg KH <greg@kroah.com> wrote: > > > > On Tue, Oct 20, 2015 at 11:58:21AM -0400, Kenneth Adam Miller wrote: > > > So I'm building a uio kernel driver with buildroot, and I've > gotten the > > driver > > > to compile, installed it and can insmod it in the final buildroot > target > > after > > > booting the image with QEMU. > > > > > > I'm on linux kernel version 3.14, and I followed the guide here: > > > > > > > https://www.kernel.org/doc/htmldocs/uio-howto/userspace_driver.html > > > > > > And it describes the location on where the device file that should > be > > opened by > > > userland code as either one of two locations: > > > > > > /dev/uioX, with X being a number > > > > > > or /sys/class/uio/uioX > > > > > > But the each of following returns nothing: > > > > > > ls /dev/uio* > > > ls /sys/class/uio/ > > > > > > After I compile the uio example that is provided in the linux > source at > > source/ > > > drivers/uio/uio.c and uio_dmem_genirq.c, and insmod them, I do > modprobe > > uio and > > > modprobe uio_dmem_genirq and each of those return nothing. > However, I do > > see > > > that /sys/modules/uio and /sys/modules/uio_dmem_genirq > > > > uio.ko is the uio "core", you need a uio driver in order to actually > use > > it. > > > > uio_dmem_genirq is a uio driver, have you added the needed device > tree > > entries to have it actually create a device for you? Without them, > this > > driver can not find any hardware to bind to, and as such, no device > node > > will ever be created. > > > > > > I didn't know about that. How do I do that? I'm using buildroot; I guess > > there's something missing in menuconfig or linux-menuconfig. > > Um, no, device tree doesn't have anything to do with buildroot, other > than the fact that you need such a thing for your platform to work > properly. > Well, often there are options and relation configurations that are implicitly required by the target development objective that have to be enabled by buildroot. For instance, right now I'm using devtempfs, and I know that because one of the things I considered was that it was possible that it was a silent failure on the part of the module insertion that it wasn't creating the current /dev entry because it was static. But I followed up in buildroot to make sure that I had it. > > > I would suggest reading the UIO documentation, it should explain all > of > > this for you already. If not, specific questions are always gladly > > answered. > > > > > > The one that I linked? I read that repeatedly. What other documentation > is > > there to read? I also read from Essential Linux Device Drivers, and none > of > > them explained that. There has to be something I'm missing. > > Step back, what exactly are you trying to do here that you think UIO is > the answer? Where is the uio driver that you want to run for your > hardware platform? UIO is a _very_ hardware-specific solution to a > _very_ specific problem that people have, are you sure it's what you > need? > > Right now, we are building a security solution that requires that communication be fully isolated by subject. We don't have special devices, we actually have very special, extra security software that we're trying to support. One of those is a permissions capability that can be set beneath the guest that determines what memory can be observed or written to. If a violation occurs, the guest is killed. We like this model because only the data makes it through. The problem with doing it the old way was 1) it was too slow. 2) it was very hard to write in a kernel module context, and therefore it was overkill 3) all we really wanted was to facilitate the ability to access special limited access memory. So effectively, we are moving code that is currently in a driver, out of a driver. In fact, all we want to do is map memory into user space, and then access that memory as though it were an array in the user land code. > thanks, > > greg k-h > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151020/6f64660e/attachment.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* UIO Kernel Driver with Buildroot and QEMU 2015-10-21 0:28 ` Kenneth Adam Miller @ 2015-10-21 0:43 ` Greg KH 2015-10-21 0:48 ` Kenneth Adam Miller 0 siblings, 1 reply; 10+ messages in thread From: Greg KH @ 2015-10-21 0:43 UTC (permalink / raw) To: kernelnewbies On Tue, Oct 20, 2015 at 08:28:20PM -0400, Kenneth Adam Miller wrote: > On Tue, Oct 20, 2015 at 8:17 PM, Greg KH <greg@kroah.com> wrote: > On Tue, Oct 20, 2015 at 07:40:37PM -0400, Kenneth Adam Miller wrote: > > I didn't know about that. How do I do that? I'm using buildroot; I guess > > there's something missing in menuconfig or linux-menuconfig. > > Um, no, device tree doesn't have anything to do with buildroot, other > than the fact that you need such a thing for your platform to work > properly. > > Well, often there are options and relation configurations that are implicitly > required by the target development objective that have to be enabled by > buildroot. For instance, right now I'm using devtempfs, and I know that because > one of the things I considered was that it was possible that it was a silent > failure on the part of the module insertion that it wasn't creating the current > /dev entry because it was static. But I followed up in buildroot to make sure > that I had it. Again, device tree is not a kernel build "option", it is provided by the firmware of your platform and handed to the kernel. It describes your hardware to the kernel for systems that do not have discoverable hardware (like USB or PCI). > >? ? ?I would suggest reading the UIO documentation, it should explain all > of > >? ? ?this for you already.? If not, specific questions are always gladly > >? ? ?answered. > > > > > > The one that I linked? I read that repeatedly. What other documentation > is > > there to read? I also read from Essential Linux Device Drivers, and none > of > > them explained that. There has to be something I'm missing.? > > Step back, what exactly are you trying to do here that you think UIO is > the answer?? Where is the uio driver that you want to run for your > hardware platform?? UIO is a _very_ hardware-specific solution to a > _very_ specific problem that people have, are you sure it's what you > need? > > Right now, we are building a security solution that requires that communication > be fully isolated by subject. We don't have special devices, we actually have > very special, extra security software that we're trying to support. One of > those is a permissions capability that can be set beneath the guest that > determines what memory can be observed or written to. If a violation occurs, > the guest is killed. We like this model because only the data makes it through. > The problem with doing it the old way was 1) it was too slow. 2) it was very > hard to write in a kernel module context, and therefore it was overkill 3) all > we really wanted was to facilitate the ability to access special limited access > memory.? How does that relate to UIO? The kernel already provides userspace isolation to memory, no need to add anything else, the hardware of the CPU does this for you automatically. > So effectively, we are moving code that is currently in a driver, out of a > driver. In fact, all we want to do is map memory into user space, and then > access that memory as though it were an array in the user land code. You don't need UIO for that, just use /dev/mem/ or other such functionality for that. UIO is to allow userspace access to physical hardware that is memory-backed, and interrupts for that hardware. If you just want access to real memory, no need to use UIO for that at all. good luck! greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* UIO Kernel Driver with Buildroot and QEMU 2015-10-21 0:43 ` Greg KH @ 2015-10-21 0:48 ` Kenneth Adam Miller 0 siblings, 0 replies; 10+ messages in thread From: Kenneth Adam Miller @ 2015-10-21 0:48 UTC (permalink / raw) To: kernelnewbies On Tue, Oct 20, 2015 at 8:43 PM, Greg KH <greg@kroah.com> wrote: > On Tue, Oct 20, 2015 at 08:28:20PM -0400, Kenneth Adam Miller wrote: > > On Tue, Oct 20, 2015 at 8:17 PM, Greg KH <greg@kroah.com> wrote: > > On Tue, Oct 20, 2015 at 07:40:37PM -0400, Kenneth Adam Miller wrote: > > > I didn't know about that. How do I do that? I'm using buildroot; I > guess > > > there's something missing in menuconfig or linux-menuconfig. > > > > Um, no, device tree doesn't have anything to do with buildroot, other > > than the fact that you need such a thing for your platform to work > > properly. > > > > Well, often there are options and relation configurations that are > implicitly > > required by the target development objective that have to be enabled by > > buildroot. For instance, right now I'm using devtempfs, and I know that > because > > one of the things I considered was that it was possible that it was a > silent > > failure on the part of the module insertion that it wasn't creating the > current > > /dev entry because it was static. But I followed up in buildroot to make > sure > > that I had it. > > Again, device tree is not a kernel build "option", it is provided by the > firmware of your platform and handed to the kernel. It describes your > hardware to the kernel for systems that do not have discoverable > hardware (like USB or PCI). > > > > I would suggest reading the UIO documentation, it should > explain all > > of > > > this for you already. If not, specific questions are always > gladly > > > answered. > > > > > > > > > The one that I linked? I read that repeatedly. What other > documentation > > is > > > there to read? I also read from Essential Linux Device Drivers, > and none > > of > > > them explained that. There has to be something I'm missing. > > > > Step back, what exactly are you trying to do here that you think UIO > is > > the answer? Where is the uio driver that you want to run for your > > hardware platform? UIO is a _very_ hardware-specific solution to a > > _very_ specific problem that people have, are you sure it's what you > > need? > > > > Right now, we are building a security solution that requires that > communication > > be fully isolated by subject. We don't have special devices, we actually > have > > very special, extra security software that we're trying to support. One > of > > those is a permissions capability that can be set beneath the guest that > > determines what memory can be observed or written to. If a violation > occurs, > > the guest is killed. We like this model because only the data makes it > through. > > The problem with doing it the old way was 1) it was too slow. 2) it was > very > > hard to write in a kernel module context, and therefore it was overkill > 3) all > > we really wanted was to facilitate the ability to access special limited > access > > memory. > > How does that relate to UIO? > > The kernel already provides userspace isolation to memory, no need to > add anything else, the hardware of the CPU does this for you > automatically. > > It provides some isolation. But there is no guarantee that any of the machine code is perfect, be it our own or the kernel's. So we take a policy where we just assume that it will have some kind of critical bug. In this case, the whole program stops - OS included. The OS does provide a version of each of the above, separation and memory isolation. But we have our own. The unique requirement that the software places on us is that we have specific hardware address regions that must be mapped to specific processes. To do that, we want to have a kernel driver map that back into user space memory. > > So effectively, we are moving code that is currently in a driver, out of > a > > driver. In fact, all we want to do is map memory into user space, and > then > > access that memory as though it were an array in the user land code. > > You don't need UIO for that, just use /dev/mem/ or other such > functionality for that. UIO is to allow userspace access to physical > hardware that is memory-backed, and interrupts for that hardware. If > you just want access to real memory, no need to use UIO for that at all. > > So dev/mem would allow the user space process to access a specific memory region? Wow, I had no idea about that. If that's the case, you've helped us tremendously because now we don't even have to write a driver at all. > good luck! > > greg k-h > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151020/92a493bb/attachment-0001.html ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-10-21 0:48 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-10-20 15:58 UIO Kernel Driver with Buildroot and QEMU Kenneth Adam Miller 2015-10-20 20:29 ` Kenneth Adam Miller 2015-10-20 21:56 ` Mandeep Sandhu 2015-10-20 22:55 ` Kenneth Adam Miller 2015-10-20 22:54 ` Greg KH 2015-10-20 23:40 ` Kenneth Adam Miller 2015-10-21 0:17 ` Greg KH 2015-10-21 0:28 ` Kenneth Adam Miller 2015-10-21 0:43 ` Greg KH 2015-10-21 0:48 ` Kenneth Adam Miller
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.