Re: When is to preempt safe?
Hi! On 19:27 Fri 07 Oct , Parmenides wrote: > Hi, > >Preemption has two cases: user preemption and kernel preemption. I > have tow questions about them. > > 1. According to Love, "If the kernel is returning to user-space, it > knows it is in a safe quiescent state. In other words, if it is safe > to continue executing the current task, it is also safe to pick a new > task to execute." What's the meaning of user preemption's safety? How > can we deduce safety of schedule from the current task going on? Basically a task running in userspace in does not hold any kernel locks (see below). > 2. Another statement from Love is that "the kernel can preempt a task > running in the kernel so long as it does not hold a lock". Why is it > not safe while kernel code holding lock? There are 2 different kind of locks: Those which can be preempted (mutex and semaphores) and those which cannot (spinlocks). Spinlocks do busy waiting until the lock is released. On single cpu systems, the are optimised into enable/disable preemption. Spinlocks have to be used if the data it protects is partly accessed in code paths which have preemption disables for other reasons (e.g. being interrupt handler). This is because otherwise you have a problem if you cannot preempt, but need to aquire a lock which is held by a "thread" which has been preempted. Also spinlocks *can* improve performance, because taking the lock tends be faster if "threads" do not go to sleep while holding the lock. However, it can also to the reverse: reducing responsiveness by running too long without preemption. -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: problem mapping physical address from /dev/mem
On Fri, Oct 7, 2011 at 3:45 AM, rohan puri wrote: > > > On Fri, Oct 7, 2011 at 3:51 PM, rohan puri wrote: > >> >> >> On Fri, Oct 7, 2011 at 3:29 PM, rohan puri wrote: >> >>> >>> >>> On Fri, Oct 7, 2011 at 12:41 PM, Vaibhav Jain wrote: >>> On Thu, Oct 6, 2011 at 9:42 PM, rohan puri wrote: > > > On Fri, Oct 7, 2011 at 4:13 AM, Vaibhav Jain wrote: > >> >> >> On Thu, Oct 6, 2011 at 11:28 AM, Mulyadi Santosa < >> mulyadi.sant...@gmail.com> wrote: >> >>> Hi... >>> >>> On Thu, Oct 6, 2011 at 02:34, Vaibhav Jain >>> wrote: >>> > Hi, >>> > >>> > I am trying to run a program that scans memory from a given >>> physical address >>> > using /dev/mem. >>> > It uses mmap to map physical address from /dev/mem. So to start >>> with I used >>> > /proc/iomem to look up the >>> > physical memory mapping and found the address 0001 to be the >>> starting >>> > address for System ram. But whenever I >>> > provide this address to the program it throws an error of >>> "Operation not >>> > permitted". >>> >>> Probably this could also due to mmap NULL dereferencing protection >>> (at >>> least that's how I name it :) ) >>> >>> By default, the lowest 65536 byte (1 in hex) is protected from >>> mapping etc. It practically render such null dererefencing useless. >>> >>> >>> -- >>> regards, >>> >>> Mulyadi Santosa >>> Freelance Linux trainer and consultant >>> >>> blog: the-hydra.blogspot.com >>> training: mulyaditraining.blogspot.com >>> >> >> Hi, >> >> I tried the same with other addresses (greater than 0x1 ) also but >> it is throwing the same error. >> Is there a way to get over this ? >> >> Thanks >> Vaibhav Jain >> >> >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> Hi Vaibhav, > > This is how it can be done. Refer link > http://www.theknotter.net/system-memory-dumps-on-linux/ > > I have attached the modified code which disables the socket creation > part and dumps the output in a file. > > Regards, > Rohan Puri > Thanks Rohan for the code but I already have a code that reads memory using /dev/mem and mmap. Only difference is I have to manually change the starting address in program. The problem is whenver I give any System RAM address the mmap call fails with 'Operation not permitted'. I googled a little and found that normally this operation is not allowed and the kernel has to be compiled with CONFIG_STRICT_DEVMEM disabled to read any memory location in this way. I also found out about the boot option 'strict-devmem =0'. I tried both these options but none of them seems to working. So I am trying to figure out if there is some other setting that I need to change. I am doing this on Fedora 15 - 2.6.38 kernel. Thanks Vaibhav Jain >>> Hi Vaibhav, >>> >>> My iomem file : - >>> >>> - : reserved >>> *0001-0009f3ff : System RAM* >>> 0009f400-0009 : reserved >>> 000c-000c7fff : Video ROM >>> 000cc000-000ccfff : Adapter ROM >>> 000cd000-000c : pnp 00:0c >>> 000e-000e : pnp 00:0c >>> 000f-000f : reserved >>> 000f-000f : System ROM >>> *0010-cf6d : System RAM* >>> 0100-015dadf2 : Kernel code >>> 015dadf3-01ab907f : Kernel data >>> 01bb1000-01d04fff : Kernel bss >>> >>> Now the program which i sent you, with that I am able to read the 1st >>> part of System RAM successfully. I am getting the operation not permitted >>> error from mmap for second part of System RAM. Can you verify the same on >>> your system. I mean are you able to read the 1st part (if your System RAM is >>> divided) or not ? >>> >>> Regards, >>> Rohan Puri >>> >> >> Another way to get the memory map is install crash module on your system >> and access the memory by accessing the new device /dev/crash instead of >> /dev/mem >> >> Regards, >> Rohan Puri >> > > Even I tried after disabling the option CONFIG_STRICT_DEVMEM, but still > cannot access the 2nd part of System RAM. Also my linux is for x86_64 arch, > hence maybe I am able to access the 1st part of System RAM though that is > above 1 MB. > > Regards, > Rohan Puri > On my system 'cat /proc/iomem' gives the following - : reserved *0001-0008efff : System RAM* 0008f000-0009 : reserved 000a-000b : PCI Bus :00 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000cd000-000d2dff : Adapter ROM 000d3000-000d53ff : Adapter ROM 000d5800-000d67ff : Adapter ROM 000d6800-000d77ff : Adapter ROM 000e-000f : reserved 000f-000f : Syst
Re: When is to preempt safe?
On Fri, Oct 07, 2011 at 07:27:12PM +0800, Parmenides wrote: > 2. Another statement from Love is that "the kernel can preempt a task > running in the kernel so long as it does not hold a lock". Why is it > not safe while kernel code holding lock? If you preempt while a lock is being held, another task could try to acquire the same lock, causing a deadlock. HTH, Jonathan Neuschäfer ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: When is to preempt safe?
On 7 Oct 2011 16:58, "Parmenides" wrote: > > Hi, > > Preemption has two cases: user preemption and kernel preemption. I > have tow questions about them. > > 1. According to Love, "If the kernel is returning to user-space, it > knows it is in a safe quiescent state. In other words, if it is safe > to continue executing the current task, it is also safe to pick a new > task to execute." What's the meaning of user preemption's safety? How > can we deduce safety of schedule from the current task going on? > > 2. Another statement from Love is that "the kernel can preempt a task > running in the kernel so long as it does not hold a lock". Why is it > not safe while kernel code holding lock? New task pick by scheduler may try to get the same lock resulting in deadlock > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [lm-sensors] [PATCH] hwmon class driver registration with a device number
On Fri, Oct 07, 2011 at 03:26:21PM +0530, Himanshu Chauhan wrote: > On Thu, Oct 06, 2011 at 11:52:37PM -0700, Greg KH wrote: > > On Fri, Oct 07, 2011 at 12:12:40PM +0530, Himanshu Chauhan wrote: > > > On Thu, Oct 06, 2011 at 12:07:52PM -0700, Guenter Roeck wrote: > > > > And why, and what for. > > > > > > The initial idea of posting to kernelnewbies was to get a hint on how > > > the patch would be taken as. I wanted to know if developers will like > > > the idea behind it or not. I guess, Guenter is not convinced with > > > any of my reasoning. I am willing to clean it up further only if > > > I get a positive hint. But it doesn't seem to be going anywhere. > > > > > > Thanks Guenter, Alan, and Greg for taking your time and reviewing it. > > > > > > Greg: To answer your last question, if this was taken positively, I > > > was thinking of having functionality similar to misc device registration. > > > > But why? What is that device node going to be used for? Who would be > > using it in userspace and where would it be tied into in the kernel? > > > The device node, as I said earlier, can be used for doing IOCTLS. It can? Which ones? New ones you want to propose? If so, why use an ioctl? > In user space, applications that manage and monitor system environment > will need to use this interface for querying the sensor's location, > for example. In side the kernel, the driver that is driving the > particular hardware sensor can register a char interface for all this > and then register with hwmon with the same major/minor for usual sysfs > export of data. So you are creating a new user/kernel api here, right? If so, you need to document it in Documentation/API and we need to be able to approve that BEFORE we could ever accept the creation of new device nodes like this, that at the moment, do not do anything. In other words, you need to prove you need a new ioctl interface before you can get a patch accepted that implements this. greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Why do processes with higher priority to be allocated more timeslice?
Missed a lot of exciting conversation. Here is the link follow it you will understand the reason of fairness http://www.linuxjournal.com/article/10267 the reason the low-priority task gets less time slice is appropriate to balance between latency and throughput. If high priority task (interactive) needs to preempt the low priority task, in such case, if the system is fully preemptive, it makes sense to give larger time slice for low priority task. If the system is completely preemptive (which is not in normal vanilla kernel), in such case the smaller time slice for low priority task becomes max latency for interactive task to get scheduled. I see in the current kernel code, there is check whether to reschedule the current execution context when returning from interrupt (top half and bottom half), checks "need_resch" field in task_struct. So, I think according to your argument you should able to increase the time slice for low priority task to decrease context switches. You can modify code and test to see what happens. Sri On Tue, Sep 27, 2011 at 11:44 AM, Mulyadi Santosa wrote: > Hi :) > > On Tue, Sep 27, 2011 at 20:06, Parmenides wrote: >> Initially, I think that the scheduler should enlarge the timeslices of >> CPU-bound processes to improve throughput. > > True :) > >>But, now I have realized >> that the two goals of schedulers, namely shorter latency and higher >> throughput, can not be achieved at the same time. Linux scheduler may >> prefer to the former. Thanks! :-) >> > > I always think that the problem is, let N is the number of the jobs, > and M is the number of processor, whenever N>M, scheduler could never > achieve ideal situation (both lower latency and higher throughput). If > at least N=M, now that's we're talkin' :) > > Another problem is actually Linux kernel is not real time kernel. It's > not really a big problem actually in most cases, but in some cases it > might e.g sound processing. Unbounded latency in non real time kernel > is a big no no in such situations. > > Just my 2 cents thought :) > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Regards, Sri. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
When is to preempt safe?
Hi, Preemption has two cases: user preemption and kernel preemption. I have tow questions about them. 1. According to Love, "If the kernel is returning to user-space, it knows it is in a safe quiescent state. In other words, if it is safe to continue executing the current task, it is also safe to pick a new task to execute." What's the meaning of user preemption's safety? How can we deduce safety of schedule from the current task going on? 2. Another statement from Love is that "the kernel can preempt a task running in the kernel so long as it does not hold a lock". Why is it not safe while kernel code holding lock? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: problem mapping physical address from /dev/mem
On Fri, Oct 7, 2011 at 3:51 PM, rohan puri wrote: > > > On Fri, Oct 7, 2011 at 3:29 PM, rohan puri wrote: > >> >> >> On Fri, Oct 7, 2011 at 12:41 PM, Vaibhav Jain wrote: >> >>> On Thu, Oct 6, 2011 at 9:42 PM, rohan puri wrote: >>> On Fri, Oct 7, 2011 at 4:13 AM, Vaibhav Jain wrote: > > > On Thu, Oct 6, 2011 at 11:28 AM, Mulyadi Santosa < > mulyadi.sant...@gmail.com> wrote: > >> Hi... >> >> On Thu, Oct 6, 2011 at 02:34, Vaibhav Jain >> wrote: >> > Hi, >> > >> > I am trying to run a program that scans memory from a given physical >> address >> > using /dev/mem. >> > It uses mmap to map physical address from /dev/mem. So to start with >> I used >> > /proc/iomem to look up the >> > physical memory mapping and found the address 0001 to be the >> starting >> > address for System ram. But whenever I >> > provide this address to the program it throws an error of "Operation >> not >> > permitted". >> >> Probably this could also due to mmap NULL dereferencing protection (at >> least that's how I name it :) ) >> >> By default, the lowest 65536 byte (1 in hex) is protected from >> mapping etc. It practically render such null dererefencing useless. >> >> >> -- >> regards, >> >> Mulyadi Santosa >> Freelance Linux trainer and consultant >> >> blog: the-hydra.blogspot.com >> training: mulyaditraining.blogspot.com >> > > Hi, > > I tried the same with other addresses (greater than 0x1 ) also but > it is throwing the same error. > Is there a way to get over this ? > > Thanks > Vaibhav Jain > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > Hi Vaibhav, This is how it can be done. Refer link http://www.theknotter.net/system-memory-dumps-on-linux/ I have attached the modified code which disables the socket creation part and dumps the output in a file. Regards, Rohan Puri >>> >>> >>> Thanks Rohan for the code but I already have a code that reads memory >>> using /dev/mem and mmap. >>> Only difference is I have to manually change the starting address in >>> program. The problem is whenver I give >>> any System RAM address the mmap call fails with 'Operation not >>> permitted'. I googled a little and found that normally >>> this operation is not allowed and the kernel has to be compiled with >>> CONFIG_STRICT_DEVMEM disabled to read any memory >>> location in this way. I also found out about the boot option >>> 'strict-devmem =0'. I tried both these options but none of them seems to >>> working. >>> So I am trying to figure out if there is some other setting that I need >>> to change. >>> I am doing this on Fedora 15 - 2.6.38 kernel. >>> >>> Thanks >>> Vaibhav Jain >>> >>> >> Hi Vaibhav, >> >> My iomem file : - >> >> - : reserved >> *0001-0009f3ff : System RAM* >> 0009f400-0009 : reserved >> 000c-000c7fff : Video ROM >> 000cc000-000ccfff : Adapter ROM >> 000cd000-000c : pnp 00:0c >> 000e-000e : pnp 00:0c >> 000f-000f : reserved >> 000f-000f : System ROM >> *0010-cf6d : System RAM* >> 0100-015dadf2 : Kernel code >> 015dadf3-01ab907f : Kernel data >> 01bb1000-01d04fff : Kernel bss >> >> Now the program which i sent you, with that I am able to read the 1st part >> of System RAM successfully. I am getting the operation not permitted error >> from mmap for second part of System RAM. Can you verify the same on your >> system. I mean are you able to read the 1st part (if your System RAM is >> divided) or not ? >> >> Regards, >> Rohan Puri >> > > Another way to get the memory map is install crash module on your system > and access the memory by accessing the new device /dev/crash instead of > /dev/mem > > Regards, > Rohan Puri > Even I tried after disabling the option CONFIG_STRICT_DEVMEM, but still cannot access the 2nd part of System RAM. Also my linux is for x86_64 arch, hence maybe I am able to access the 1st part of System RAM though that is above 1 MB. Regards, Rohan Puri ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: problem mapping physical address from /dev/mem
On Fri, Oct 7, 2011 at 3:29 PM, rohan puri wrote: > > > On Fri, Oct 7, 2011 at 12:41 PM, Vaibhav Jain wrote: > >> On Thu, Oct 6, 2011 at 9:42 PM, rohan puri wrote: >> >>> >>> >>> On Fri, Oct 7, 2011 at 4:13 AM, Vaibhav Jain wrote: >>> On Thu, Oct 6, 2011 at 11:28 AM, Mulyadi Santosa < mulyadi.sant...@gmail.com> wrote: > Hi... > > On Thu, Oct 6, 2011 at 02:34, Vaibhav Jain wrote: > > Hi, > > > > I am trying to run a program that scans memory from a given physical > address > > using /dev/mem. > > It uses mmap to map physical address from /dev/mem. So to start with > I used > > /proc/iomem to look up the > > physical memory mapping and found the address 0001 to be the > starting > > address for System ram. But whenever I > > provide this address to the program it throws an error of "Operation > not > > permitted". > > Probably this could also due to mmap NULL dereferencing protection (at > least that's how I name it :) ) > > By default, the lowest 65536 byte (1 in hex) is protected from > mapping etc. It practically render such null dererefencing useless. > > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > Hi, I tried the same with other addresses (greater than 0x1 ) also but it is throwing the same error. Is there a way to get over this ? Thanks Vaibhav Jain ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Hi Vaibhav, >>> >>> This is how it can be done. Refer link >>> http://www.theknotter.net/system-memory-dumps-on-linux/ >>> >>> I have attached the modified code which disables the socket creation part >>> and dumps the output in a file. >>> >>> Regards, >>> Rohan Puri >>> >> >> >> Thanks Rohan for the code but I already have a code that reads memory >> using /dev/mem and mmap. >> Only difference is I have to manually change the starting address in >> program. The problem is whenver I give >> any System RAM address the mmap call fails with 'Operation not permitted'. >> I googled a little and found that normally >> this operation is not allowed and the kernel has to be compiled with >> CONFIG_STRICT_DEVMEM disabled to read any memory >> location in this way. I also found out about the boot option >> 'strict-devmem =0'. I tried both these options but none of them seems to >> working. >> So I am trying to figure out if there is some other setting that I need to >> change. >> I am doing this on Fedora 15 - 2.6.38 kernel. >> >> Thanks >> Vaibhav Jain >> >> > Hi Vaibhav, > > My iomem file : - > > - : reserved > *0001-0009f3ff : System RAM* > 0009f400-0009 : reserved > 000c-000c7fff : Video ROM > 000cc000-000ccfff : Adapter ROM > 000cd000-000c : pnp 00:0c > 000e-000e : pnp 00:0c > 000f-000f : reserved > 000f-000f : System ROM > *0010-cf6d : System RAM* > 0100-015dadf2 : Kernel code > 015dadf3-01ab907f : Kernel data > 01bb1000-01d04fff : Kernel bss > > Now the program which i sent you, with that I am able to read the 1st part > of System RAM successfully. I am getting the operation not permitted error > from mmap for second part of System RAM. Can you verify the same on your > system. I mean are you able to read the 1st part (if your System RAM is > divided) or not ? > > Regards, > Rohan Puri > Another way to get the memory map is install crash module on your system and access the memory by accessing the new device /dev/crash instead of /dev/mem Regards, Rohan Puri ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: problem mapping physical address from /dev/mem
On Fri, Oct 7, 2011 at 12:41 PM, Vaibhav Jain wrote: > On Thu, Oct 6, 2011 at 9:42 PM, rohan puri wrote: > >> >> >> On Fri, Oct 7, 2011 at 4:13 AM, Vaibhav Jain wrote: >> >>> >>> >>> On Thu, Oct 6, 2011 at 11:28 AM, Mulyadi Santosa < >>> mulyadi.sant...@gmail.com> wrote: >>> Hi... On Thu, Oct 6, 2011 at 02:34, Vaibhav Jain wrote: > Hi, > > I am trying to run a program that scans memory from a given physical address > using /dev/mem. > It uses mmap to map physical address from /dev/mem. So to start with I used > /proc/iomem to look up the > physical memory mapping and found the address 0001 to be the starting > address for System ram. But whenever I > provide this address to the program it throws an error of "Operation not > permitted". Probably this could also due to mmap NULL dereferencing protection (at least that's how I name it :) ) By default, the lowest 65536 byte (1 in hex) is protected from mapping etc. It practically render such null dererefencing useless. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com >>> >>> Hi, >>> >>> I tried the same with other addresses (greater than 0x1 ) also but it >>> is throwing the same error. >>> Is there a way to get over this ? >>> >>> Thanks >>> Vaibhav Jain >>> >>> >>> >>> ___ >>> Kernelnewbies mailing list >>> Kernelnewbies@kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >>> Hi Vaibhav, >> >> This is how it can be done. Refer link >> http://www.theknotter.net/system-memory-dumps-on-linux/ >> >> I have attached the modified code which disables the socket creation part >> and dumps the output in a file. >> >> Regards, >> Rohan Puri >> > > > Thanks Rohan for the code but I already have a code that reads memory using > /dev/mem and mmap. > Only difference is I have to manually change the starting address in > program. The problem is whenver I give > any System RAM address the mmap call fails with 'Operation not permitted'. > I googled a little and found that normally > this operation is not allowed and the kernel has to be compiled with > CONFIG_STRICT_DEVMEM disabled to read any memory > location in this way. I also found out about the boot option 'strict-devmem > =0'. I tried both these options but none of them seems to working. > So I am trying to figure out if there is some other setting that I need to > change. > I am doing this on Fedora 15 - 2.6.38 kernel. > > Thanks > Vaibhav Jain > > Hi Vaibhav, My iomem file : - - : reserved *0001-0009f3ff : System RAM* 0009f400-0009 : reserved 000c-000c7fff : Video ROM 000cc000-000ccfff : Adapter ROM 000cd000-000c : pnp 00:0c 000e-000e : pnp 00:0c 000f-000f : reserved 000f-000f : System ROM *0010-cf6d : System RAM* 0100-015dadf2 : Kernel code 015dadf3-01ab907f : Kernel data 01bb1000-01d04fff : Kernel bss Now the program which i sent you, with that I am able to read the 1st part of System RAM successfully. I am getting the operation not permitted error from mmap for second part of System RAM. Can you verify the same on your system. I mean are you able to read the 1st part (if your System RAM is divided) or not ? Regards, Rohan Puri ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [lm-sensors] [PATCH] hwmon class driver registration with a device number
On Thu, Oct 06, 2011 at 11:52:37PM -0700, Greg KH wrote: > On Fri, Oct 07, 2011 at 12:12:40PM +0530, Himanshu Chauhan wrote: > > On Thu, Oct 06, 2011 at 12:07:52PM -0700, Guenter Roeck wrote: > > > And why, and what for. > > > > The initial idea of posting to kernelnewbies was to get a hint on how > > the patch would be taken as. I wanted to know if developers will like > > the idea behind it or not. I guess, Guenter is not convinced with > > any of my reasoning. I am willing to clean it up further only if > > I get a positive hint. But it doesn't seem to be going anywhere. > > > > Thanks Guenter, Alan, and Greg for taking your time and reviewing it. > > > > Greg: To answer your last question, if this was taken positively, I > > was thinking of having functionality similar to misc device registration. > > But why? What is that device node going to be used for? Who would be > using it in userspace and where would it be tied into in the kernel? > The device node, as I said earlier, can be used for doing IOCTLS. In user space, applications that manage and monitor system environment will need to use this interface for querying the sensor's location, for example. In side the kernel, the driver that is driving the particular hardware sensor can register a char interface for all this and then register with hwmon with the same major/minor for usual sysfs export of data. -Himanshu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: problem mapping physical address from /dev/mem
On Thu, Oct 6, 2011 at 9:42 PM, rohan puri wrote: > > > On Fri, Oct 7, 2011 at 4:13 AM, Vaibhav Jain wrote: > >> >> >> On Thu, Oct 6, 2011 at 11:28 AM, Mulyadi Santosa < >> mulyadi.sant...@gmail.com> wrote: >> >>> Hi... >>> >>> On Thu, Oct 6, 2011 at 02:34, Vaibhav Jain wrote: >>> > Hi, >>> > >>> > I am trying to run a program that scans memory from a given physical >>> address >>> > using /dev/mem. >>> > It uses mmap to map physical address from /dev/mem. So to start with I >>> used >>> > /proc/iomem to look up the >>> > physical memory mapping and found the address 0001 to be the >>> starting >>> > address for System ram. But whenever I >>> > provide this address to the program it throws an error of "Operation >>> not >>> > permitted". >>> >>> Probably this could also due to mmap NULL dereferencing protection (at >>> least that's how I name it :) ) >>> >>> By default, the lowest 65536 byte (1 in hex) is protected from >>> mapping etc. It practically render such null dererefencing useless. >>> >>> >>> -- >>> regards, >>> >>> Mulyadi Santosa >>> Freelance Linux trainer and consultant >>> >>> blog: the-hydra.blogspot.com >>> training: mulyaditraining.blogspot.com >>> >> >> Hi, >> >> I tried the same with other addresses (greater than 0x1 ) also but it >> is throwing the same error. >> Is there a way to get over this ? >> >> Thanks >> Vaibhav Jain >> >> >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> Hi Vaibhav, > > This is how it can be done. Refer link > http://www.theknotter.net/system-memory-dumps-on-linux/ > > I have attached the modified code which disables the socket creation part > and dumps the output in a file. > > Regards, > Rohan Puri > Thanks Rohan for the code but I already have a code that reads memory using /dev/mem and mmap. Only difference is I have to manually change the starting address in program. The problem is whenver I give any System RAM address the mmap call fails with 'Operation not permitted'. I googled a little and found that normally this operation is not allowed and the kernel has to be compiled with CONFIG_STRICT_DEVMEM disabled to read any memory location in this way. I also found out about the boot option 'strict-devmem =0'. I tried both these options but none of them seems to working. So I am trying to figure out if there is some other setting that I need to change. I am doing this on Fedora 15 - 2.6.38 kernel. Thanks Vaibhav Jain ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
