scull_init_module() in scull driver
Hi, guys:
I am reading function scull_init_module() in scull driver.I found that
scull_init_module() doesn't check scull_setup_cdev()'s return value.If
there will be a probem when scull_setup_cdev() failed, and then, others
call scull_cleanup_module()?
for (i = 0; i scull_nr_devs; i++) {
scull_devices[i].quantum = scull_quantum;
scull_devices[i].qset = scull_qset;
init_MUTEX(scull_devices[i].sem);
scull_setup_cdev(scull_devices[i], i);
}
Best Regard
Rock Lee
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Learning things
On 07/04/15 05:06, Anupam Kapoor wrote: [2015-04-07T00:08:10+0530]: Mike Thompson (mike-thompson): ,[ mike-thompson ] | As others mention, using the Linux kernel to come up to speed with C is the | wrong approach. If you have a strong desire to learn kernel programming | concepts while coming up to speed on C, I would suggest getting the latest | book on Xinu, buying an Intel Galileo board and working your way through | that book. Xinu is what I cut my teeth on 25 years ago and I remember it | being a terrific learning environment. Xinu is not Linux (or Unix), but | for starting at the ground level all the concepts will map over when you | are ready to tackle Linux kernel work. | | Information for Xinu can be found here: http://www.xinu.cs.purdue.edu/ ` or there is always xv6 (http://pdos.csail.mit.edu/6.828/2014/) which might be useful... There is also OS161 or Plan9, these should be enough names to search for comparisons or discussions on the OS's to help you pick one. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: VFS/driver core overhead
On Mon, 06 Apr 2015 23:12:34 -0400, nick said: (Replying mostly for the edification of those who can learn learn without having to be spoon-fed) After reading through the code for the usb and vfs core infrastructure, I was wondering if after reading it if I am correct in my notion of there being very little overhead or none at all int these areas of the kernel. This is due to be noticing most drivers and file systems wrap around the core/vfs and therefore the overhead is very little and no need to worry about it like the overhead of the kernel's process structures based off task_struct For bonus points, go learn the difference between latency and throughput, and who cares about excessive overhead on each, and under what conditions, and what solutions have already been tried to address the issue. .Honestly, I could benchmark this area of the kernel but it's hard to remove the file system/drivers interfering with my benchmarks due to me not knowing of any one way to do that. If someone either points me to a benchmark for me to test this or answers it that would be very helpful. Step -1: Go back and re-read the recent postings about diagnosing slow kernel builds, because you apparently didn't actually learn anything from them. Step 0: Learn enough about proper benchmarking and the thing you're benchmarking to be able to ask a meaningful, answerable question. Step 1: Go find the proper tool for testing your question. Step 2: Do the measurement needed to answer your question. pgpbkx0OJihUa.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Learning things
Malte Vesper wrote: On 07/04/15 05:06, Anupam Kapoor wrote: [2015-04-07T00:08:10+0530]: Mike Thompson (mike-thompson): ,[ mike-thompson ] | As others mention, using the Linux kernel to come up to speed with C is the | wrong approach. If you have a strong desire to learn kernel programming | concepts while coming up to speed on C, I would suggest getting the latest | book on Xinu, buying an Intel Galileo board and working your way through | that book. Xinu is what I cut my teeth on 25 years ago and I remember it | being a terrific learning environment. Xinu is not Linux (or Unix), but | for starting at the ground level all the concepts will map over when you | are ready to tackle Linux kernel work. | | Information for Xinu can be found here: http://www.xinu.cs.purdue.edu/ ` or there is always xv6 (http://pdos.csail.mit.edu/6.828/2014/) which might be useful... There is also OS161 or Plan9, these should be enough names to search for comparisons or discussions on the OS's to help you pick one. Of course, one might note that Linux started as a personal project. If you know something about operating systems, a historical look through the kernal might not be a bad way to start learning C. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: cross-compiling kernel using a 32-bit toolchain on a 64-bit machine
Edit .config and set CONFIG_CROSS_COMPILE to the path where your cross compiler is located. This doesn't help either! :/ I'll start afresh. Maybe my setup got messed-up somehow. Thanks anyway! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: cross-compiling kernel using a 32-bit toolchain on a 64-bit machine
On Mon, Apr 6, 2015 at 11:50 PM, Mandeep Sandhu mandeepsandhu@gmail.com wrote: Hi All, I'm having trouble compiling my kernel using a 32-bit toolchain (for ARM) on a 64-bit host (Ubuntu 14.10). The kernel version is 3.14.17. I understand that 32-bit binaries require ia32-libs (or equivalent) for compiling on 64-bit hosts. I installed the required packages (lib32z1 lib32ncurses5 lib32bz2-1.0 for Ubuntu 14.10), but still keep getting errors: $ make CROSS_COMPILE=arm-none-linux-gnueabi- all Makefile:616: Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by compiler make: arm-none-linux-gnueabi-gcc: Command not found Have built this toolchain or just downloaded from coudesourcery ? Go to the source where you downloaded toolchain (on your machine not the website) traverse to bin directory and try ./arm-none-linux-gnueabi-gcc --version. Cheers, --Prabhakar Lad ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Question about shared interrupts in devicetree
Hi Mark,
[add some possible interested developer in CC]
Mark Rutland mark.rutl...@arm.com hat am 7. April 2015 um 13:29 geschrieben:
On Sat, Apr 04, 2015 at 10:40:13PM +0100, Stefan Wahren wrote:
Hi,
Hi,
i'm currently working on drivers (regulator and power switch) for a power
subsystem of a ARM9 processor (Freescale i.MX28). There are interrupts for
the
power subsystem which share the same interrupt line. This interrupt line is
needed by both drivers (regulator and power switch).
Now the question what is the right way (tm) to specify the interrupt in the
devicetree and fetch the irq number during driver probe?
If the interrupts are generated by the subsystem as a whole, then A
would be more correct. If you can read some shared register to determine
the particular sub-block which generated the interrupt, A would
certainly be the right way of describing the HW.
If the subsystem is just a logical grouping, and the two units generate
separate interrupts which simply get muxed together (with nothing
special done at the subsystem level), then B would seem more correct, as
the two units are effectively independent.
It really depends on way the HW is organised, and how the HW _could_ be
organised if reused, so this is a grey area generally.
It looks like it would be possible to support both styles if we need to
(by checking the node first, then its parent), if we go for one option
and later discover we need the other.
thanks for the good explanation. After looking into the reference manual [1] of
the i.MX28 i still can't decide if the subsystem generate the interrupts as a
whole or
as a logical group. I only found this para in chapter 11.11:
The VDDA_BO_IRQ, VDDD_BO_IRQ, VDDIO_BO_IRQ, and BATT_BO_IRQ each
have their own interrupt line back to the interrupt collector.
However, the remaining five interrupts—VDD5V_GT_VDDIO_IRQ, DC_OK_IRQ,
VBUSVALID_IRQ, LINREG_OK_IRQ and PSWITCH_IRQ—all share a single
interrupt line. In this case, software must read the interrupt status
bits to discover which event caused the interrupt.
In my case DC_OK_IRQ and PSWITCH_IRQ are relevant.
Maybe someone else has a idea?
Thanks Stefan
[1] - http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf
Document Number: MCIMX28RM
Rev 2, 08/2013
Thanks,
Mark.
Option A (define interrupt in parent node):
power: power@80044000 {
compatible = fsl,imx28-power, syscon;
reg = 0x80044000 0x2000;
interrupts = 6;
reg_vddd: regulator@1 {
compatible = fsl,imx28-vddd;
};
pswitch: pswitch@5 {
compatible = fsl,mxs-pswitch;
linux,code = 116;
};
}
int irq = irq_of_parse_and_map(parent, 0);
Option B (define interrupt for each child node):
power: power@80044000 {
compatible = fsl,imx28-power, syscon;
reg = 0x80044000 0x2000;
reg_vddd: regulator@1 {
compatible = fsl,imx28-vddd;
interrupts = 6;
};
pswitch: pswitch@5 {
compatible = fsl,mxs-pswitch;
linux,code = 116;
interrupts = 6;
};
}
int irq = platform_get_irq(pdev, 0);
Best regards
Stefan
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: cross-compiling kernel using a 32-bit toolchain on a 64-bit machine
So I found the issue (it was a PIBKAC issue :/) I was using sudo to try and build the kernel (this was due to a messed up setup where the whole kernel src tree ended up being written by root). When copy-pasting my command here, I missed copying the sudo part and that was precisely the reason for the error. When invoking sudo, I think the current shells environment variables are not copied (probably due to security reasons) and that's why it was not picking up the toolchain paths. Once I fixed the permissions on the source tree and invoke make as regular user, it started working. Sorry about the noise, I should've figured this out earlier. On Tue, Apr 7, 2015 at 9:15 AM, Lad, Prabhakar prabhakar.cse...@gmail.com wrote: On Mon, Apr 6, 2015 at 11:50 PM, Mandeep Sandhu mandeepsandhu@gmail.com wrote: Hi All, I'm having trouble compiling my kernel using a 32-bit toolchain (for ARM) on a 64-bit host (Ubuntu 14.10). The kernel version is 3.14.17. I understand that 32-bit binaries require ia32-libs (or equivalent) for compiling on 64-bit hosts. I installed the required packages (lib32z1 lib32ncurses5 lib32bz2-1.0 for Ubuntu 14.10), but still keep getting errors: $ make CROSS_COMPILE=arm-none-linux-gnueabi- all Makefile:616: Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by compiler make: arm-none-linux-gnueabi-gcc: Command not found Have built this toolchain or just downloaded from coudesourcery ? Go to the source where you downloaded toolchain (on your machine not the website) traverse to bin directory and try ./arm-none-linux-gnueabi-gcc --version. Cheers, --Prabhakar Lad ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Out of openat flag space
Hello, Now that we have O_TMPFILE and O_BENEATH added to the openat flags, there is no space left to add more flags since the flags variable is a 32 bit int. How does one resolve this issue and extend this? A new syscall with a 64bit wide flags support? http://www.spinics.net/lists/fstests/msg01064.html Thanks David ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: cross-compiling kernel using a 32-bit toolchain on a 64-bit machine
On Mon, Apr 6, 2015 at 5:27 PM, John de la Garza j...@jjdev.com wrote: On Mon, Apr 06, 2015 at 03:50:41PM -0700, Mandeep Sandhu wrote: I'm having trouble compiling my kernel using a 32-bit toolchain (for ARM) on a 64-bit host (Ubuntu 14.10). The kernel version is 3.14.17. Any hints on how to get make to use the toolchain? after you export CROSS_COMPILE export ARCH=arm This didn't help. I get the same error as before. Thanks, -mandeep ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Out of openat flag space
On April 7, 2015 1:05:42 PM EDT, David Legault legault.da...@gmail.com wrote: Hello, Now that we have O_TMPFILE and O_BENEATH added to the openat flags, there is no space left to add more flags since the flags variable is a 32 bit int. How does one resolve this issue and extend this? A new syscall with a 64bit wide flags support? http://www.spinics.net/lists/fstests/msg01064.html Thanks David That would be the easiest way to my knowledge. However with anything system call related, test it out in every way you can think of as not to break user space applications using this call already . I am curious through as to your reasoning for changing this system call as generally this is only done only with either a very good reason or when it is a must. Hope this helps, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
maybe dumb question about RCU
Hi all,
I've been trying to understand the usage of RCU and am struggling a bit with
one issue.
Let's say one intends to use classic RCU as described in whatisRCU.txt where
readers use
sequences of rcu_read_lock(), rcu_dereference(), rcu_read_unlock) and updaters
use
rcu_assign_pointer()/synchronize_rcu().
If one uses rcu_dereference() to access an RCU protect pointer twice within the
same rcu
read locked critical section, is it guaranteed that the pointers returned by
rcu_dereference()
will point to the same block of memory?
For instance, in the following code (trying make this as simple as possible
even if it does nothing useful):
char *global;
char x[1];
char y[1];
void reader(void)
{
char *a;
char *b;
rcu_read_lock();
a = rcu_dereference(global);
b = rcu_dereference(global);
rcu_read_unlock();
}
void updater(void)
{
rcu_assign_pointer(global, x);
rcu_assign_pointer(global, y);
}
Following the second call to rcu_deference() in reader(), is it guaranteed that
a and b will be
equal (either both equal to x or both equal y)? Or is it possible what a will
equal x and b will equal y?
whatisRCU.txt seems to imply that though this is bad practice because its
wasteful, both calls
to rcu_dereference() will return the same pointer:
228 rcu_dereference()
...
244 Common coding practice uses rcu_dereference() to copy an
245 RCU-protected pointer to a local variable, then dereferences
246 this local variable, for example as follows:
247
248 p = rcu_dereference(head.next);
249 return p-data;
250
251 However, in this case, one could just as easily combine these
252 into one statement:
253
254 return rcu_dereference(head.next)-data;
255
256 If you are going to be fetching multiple fields from the
257 RCU-protected structure, using the local variable is of
258 course preferred. Repeated rcu_dereference() calls look
259 ugly and incur unnecessary overhead on Alpha CPUs.
From lines 256 to 259 I conclude that reader()'s code is considered ugly and
wasteful,
but a will always equal b.
But looking at how rcu_dereference() and rcu_assign_pointer() are implemented,
I'm having a
hard time seeing how reader() would always see a and b equal.
Thanks in advance,
Jeff Haran
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: maybe dumb question about RCU
256 If you are going to be fetching multiple fields from the
257 RCU-protected structure, using the local variable is of
258 course preferred. Repeated rcu_dereference() calls look
259 ugly and incur unnecessary overhead on Alpha CPUs.”
From lines 256 to 259 I conclude that reader()’s code is considered
ugly and wasteful,
but a will always equal b.
But looking at how rcu_dereference() and rcu_assign_pointer() are
implemented, I’m having a
hard time seeing how reader() would always see a and b equal.
This is the implementation of rcu_dereference(). It is a little old, but
useful as well.
#define rcu_dereference(p) ({ \
typeof(p) _p1 = ACCESS_ONCE(p); \
smp_read_barrier_depends(); \
(_p1); \
})
It uses memory barrier to guarantee the order of code execution.
rcu_read_lock() actually disables preemption, so writer has no chance to
modify critical section in the rcu_read_lock()/rcu_read_unlock() pair.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
