Can two different kernel modules gain access to the same area of memory from a call to ioremap_nocache() ?

I have a wireless driver, and a separate module, I would like the separate module to profile the noise values on the card, whilst the driver is still operating. Hence my question above.

One avenue I explored was to start a kernel thread from the driver, I then implemented a semaphore to prevent any race conditions arising from concurrent read/writes to the same address space. I hoped that a child thread would be able to access the same area of memory.

Unfortunately this has not worked as I expected. I would appreciate any suggestions.

  • Why would you need a kernel module to profile the noise values? – gertvdijk Jan 28 '13 at 16:10
  • Thanks for the question, the wireless driver is very complex, and to alter the periodicity of it calibrations might induce some unintended results. I would have to do this since it only does its calibrations for intervals that are much too long for my needs. Since I know exactly how to profile the device in a separate module, I am just curious to know if I can gain access to the same area of memory that the driver is working with. – Radagasp Jan 28 '13 at 16:15
  • 2
    Please edit your question to include all the details on your previous attempts/approaches. That is how this site works. It's not a discussion forum, but a Q&A site, you see? – gertvdijk Dec 2 '13 at 12:43
  • Discussion may include questions, and answers, some right and others wrong - it seems the interpretation of rules across the admins, is in the province of semantics. I have of course updated my question. – Radagasp Dec 9 '13 at 10:10

I supose you intend to implement another kernel module as you think it is easier to share data between kernel modules. But perhaps it is not a good choice. If it is possible to 'profile the noise' in user space, I think a better solution is to implement the 'profiler' in user space.

In this solution, the user space profiler reads data, performe some calculations, and than submit the result.

If this solution is ok, the implementation is as follows.

In the kernel module, it is just to register a char device in '/proc' and implement 'read' and 'write' primitives. In user space, is just to implement the profiler, reading and writing to the char device. Details and information for this implementation is all here.

  • I don't think I quite get your answer... as I understand it, I would still need to write a module, and this module would try gain access to the same area of memory from a call to ioremap_nocache() that the other module is using. Or are you saying that I register the char device in the wireless module – Radagasp Dec 9 '13 at 12:21
  • 1
    Right, you'll have to implement a software, but not a module. You will have to write a normal user space program, simpler than a module, that reads from '/dev/nameofdevice' and writes to it. No need to use 'ioremap_nocache()', just syscalls as 'open', 'read', 'write', 'close'. And yes, the wireless module will have to register the char device '/dev/nameofdevice' inside, to expose the data to userland. – vitorafsr Dec 12 '13 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.