October 2012 - kernelnewbies@kernelnewbies.org

Sleep or Suspend problems
by captain Oct. 13, 2012

Oct. 13, 2012

I'm still learning the ropes here and working my way through both "Linux Kernel in a Nutshell" and "Linux Device Drivers" but not finished as yet, so it might be premature on my part to ask this question. I don't think finishing either book will answer the question so I'll risk it. I'm running OpenSuse (11.1 I think) which has a "3.1.10-1.16-desktop" Kernel. In order to learn the ropes and move towards contribution I've built the 3.6.0 Kernel and with the help of "Linux Kernel in a Nutshell" have compiled into the kernel all the modules which OpenSuse's 3.1.10 kernel was using. So I've all the modules in there. My problem is that the when I shut down the lid of the netbook both kernel's Sleep or Suspend (not sure which is which) and flash a light to signify that the netbook is suspended. Now on the 3.1.10 kernel when I reopen the netbook it comes back to life and everybody is happy. When I reopen the 3.6.0 Kernel, even though the led is flashing to signify that the computer is asleep or suspended, the computer goes back to BIOS powerup. So a complete reset is initiated. I'm not going to ask ye to fix this but I'm wondering how do I start finding the source of this problem? I've looked in /var/log/messages and nothing as yet jumps out at me. I suppose I really need to have some idea what module in the kernel I should be looking into but there's a lot of ACPI modules in there. If anyone could suggest how one proceeds I'd be very grateful.

1 0

Mapping socket to task
by Lal Oct. 12, 2012

Oct. 12, 2012

How to get task_struct of a socket owner process? i.e. how to get task_struct* from sock* I have tried following (on 2.6.38) but didn't work. struct sock* sk = xxx; (i) sk->sk_socket->file->f_cred->uid (ii) tsk = get_pid_task(sk->sk_socket->file->f_owner->pid, sk->sk_socket->file->f_owner->pid_type) The goal is know which process opened the socket. (I know netstat -p option, and /proc/<pid>/fd methods, but I want to do it in kernel module only). Thank you Lal

2 1

smp_rmb() in consume_skb
by Kshemendra KP Oct. 11, 2012

Oct. 11, 2012

Hi, When I was looking into consume_skb() routine (net/core/skbuff.c), there is smp_rmb() read barrier is present. It is not clear why this is needed here. Basically this routine frees sk_buff if only one user reference is theere void consume_skb(struct sk_buff * skb) { if (unlikely(!skb)) return; if (likley (atomic_read (&skb->users) == 1)) smp_rmb() --------------------------------------------------------> need for this barrier ...... __kfree_skb(); } Regards Kshemendra

2 1

aio / ioctl / sideband informations
by EVS Hardware Dpt Oct. 11, 2012

Oct. 11, 2012

Hi, I'm currently converting my windows driver for a broadcast video card to Linux. This conversion raised a lot of questions/issues, and I believe I solved most of them. Yet, I still have some issues and would like some advice. In windows video data acquisition and playing were done through asynchronous IOCTL calls. I used METHOD_NEITHER for reference. The whole mechanism is simple, let's take an example for play : - User mode has a Video Buffer, an Audio Buffer and an Ancillary data buffer (Timecode, and other smpte's stuff). - User mode create a struct that gives 3 pointers to the buffers (Audio/Video/Anc) and also various sideband info (Nb of audio samples, size of buffers? ...), and call my IOCTL : IOCTL_PLAY_NEW_FRAME - In my driver, I store sideband info in an internal structure, I map all 3 buffers into Physical Memory, then I start a Dma Transfer to the Board (using SG I/O). - The card trig an Interrupt and I complete the request. Now on Linux : I first though that I would simply use ioctl capability to achieve that kind of functionnality. Using flag O_DIRECT, I had the feeling that it was possible. BUT if you have been attentive to the previous parts, you'll see that I've mentioned the fact that these ioctls were asynchronous. And that is my issue. I don't think that ioctl can be managed as aio read/write. I need the async functionnality to allow user mode post many play buffer, and to have the driver accumulate them in a fifo until that fifo is full. I see that there are aio_write facilities that match perfectly my async scenario, but I can't find a way to supply multiple buffers (all part of the same frame) along a description of what is in these buffers. I think of a workaround that would be for a single play frame: BASIC_PLAY_FRAME_OPERATION - Use io_submit to submit a write op to the driver. In the buffer, have in fact a structure representing the frame I want to send including the 3 usermode buffers. I assume that if I do not set O_DIRECT Flag, the buffer will be copied into kernel space so that I can access it with __copy_from_user. - The driver then maps and lock the 3 buffers in physical memory and trig a SG DMA transfer. - Once the transfer is done (interrupt driven), complete the aio. END_OF_BASIC_PLAY_FRAME_OPERATION To achieve the final goal, submit multiple BASIC_PLAY_FRAME_OPERATION. So my questions : - Do you believe that my proposed workaround will work ? - Are there other simpler alternatives ? Thanks for you answers/comments. Regards, Fred.

2 4

Regarding driver interface for user space
by Rahul Bedarkar Oct. 11, 2012

Oct. 11, 2012

Hi, What interfaces are provided by device drivers, in general, to user space to access status and other information ? For example, if have enabled rotatry encoder driver and touchscreen driver, how can write code in my application which will process rotatry encoder data like how many relative or absolute rotation happened, if these were clockwise or counter clockwise, etc. And in case of touchscreen driver, touch events ? Thanks, Rahul Bedarkar

2 1

kobj_attribute and followup to earlier post
by Robert P. J. Day Oct. 11, 2012

Oct. 11, 2012

just to add a bit more to what i posted/asked earlier regarding sysfs attributes and show()/store() routines, here's the declaration of the very generic kobj_attribute from kobject.h: struct kobj_attribute { struct attribute attr; ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr, char *buf); ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr, const char *buf, size_t count); }; note first that the show/store routines for kobj_attribute *do* include an actual kobj_attribute pointer (as the second arg), so it's possible to define a single pair of callback routines that handles a number of kobject attributes, given that those routines can check and distinguish between them. but that's not always what happens. note first how sysfs.h supplies a couple macros that can make defining attributes really convenient: #define __ATTR(_name,_mode,_show,_store) { \ .attr = {.name = __stringify(_name), .mode = _mode }, \ .show = _show, \ .store = _store, \ } #define __ATTR_RO(_name) { \ .attr = { .name = __stringify(_name), .mode = 0444 }, \ .show = _name##_show, \ } note how (interestingly), while the general __ATTR macro still allows you to specify the show and store routines, the __ATTR_RO macro for defining read-only attributes *forces* the show routine to be constructed using the name of the attribute itself, which then forces each attribute to need its own show routine, even if a number of them could have shared the same callback. this happens in, for example, mm/ksm.c: #define KSM_ATTR_RO(_name) \ static struct kobj_attribute _name##_attr = __ATTR_RO(_name) #define KSM_ATTR(_name) \ static struct kobj_attribute _name##_attr = \ __ATTR(_name, 0644, _name##_show, _name##_store) ... snip ... KSM_ATTR(sleep_millisecs); KSM_ATTR(pages_to_scan); KSM_ATTR(run); KSM_ATTR_RO(pages_shared); KSM_ATTR_RO(pages_sharing); KSM_ATTR_RO(pages_unshared); KSM_ATTR_RO(pages_volatile); KSM_ATTR_RO(full_scans); ... snip ... so all of those KSM_ATTR_RO-defined attributes are forced to have separate show() routines, which is fine. another example is drivers/staging/speakup/kobjects.c, which also combines the two approaches: /* * Declare the attributes. */ static struct kobj_attribute keymap_attribute = __ATTR(keymap, ROOT_W, keymap_show, keymap_store); static struct kobj_attribute silent_attribute = __ATTR(silent, USER_W, NULL, silent_store); static struct kobj_attribute synth_attribute = __ATTR(synth, USER_RW, synth_show, synth_store); static struct kobj_attribute synth_direct_attribute = __ATTR(synth_direct, USER_W, NULL, synth_direct_store); static struct kobj_attribute version_attribute = __ATTR_RO(version); static struct kobj_attribute delimiters_attribute = __ATTR(delimiters, USER_RW, punc_show, punc_store); static struct kobj_attribute ex_num_attribute = __ATTR(ex_num, USER_RW, punc_show, punc_store); static struct kobj_attribute punc_all_attribute = __ATTR(punc_all, USER_RW, punc_show, punc_store); static struct kobj_attribute punc_most_attribute = __ATTR(punc_most, USER_RW, punc_show, punc_store); static struct kobj_attribute punc_some_attribute = __ATTR(punc_some, USER_RW, punc_show, punc_store); static struct kobj_attribute repeats_attribute = __ATTR(repeats, USER_RW, punc_show, punc_store); ... anip ... here, we have some attributes defined with distinct show/store callbacks, while others are defined to *share* a pair of routines (punc_show, punc_store), which uses the attribute name to determine what to do. finally, at the top of that very source file, we read: * This code is based on kobject-example.c, which came with linux 2.6.x. well, ok, except that i don't think samples/kobject/kobject-example.c really drives home the variations of defining sysfs attributes. in any event, this still brings me back to my original curiosity -- why were *some* sysfs attribute show/store callbacks defined as accepting an attribute pointer (allowing them to multiplex among attributes) while others weren't? was there some rationale for this? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

why only some sysfs attribute callbacks use attribute pointers?
by Robert P. J. Day Oct. 11, 2012

Oct. 11, 2012

first time poking around in the sysfs attributes code and i'm a bit puzzled by something i found, i'm sure someone here (mulyadi? :-) will know the answer. the header file <linux/device.h> declares a number of show/store routines for various attribute types. for instance, here's for class: ssize_t (*show)(struct class *class, struct class_attribute *attr, char *buf); ssize_t (*store)(struct class *class, struct class_attribute *attr, const char *buf, size_t count); the above suggests that, since the show() and store() routines for class attributes take both a pointer to a class struct *AND* a pointer to an attribute itself, the same pair of routines can be used generally for a number of distinct class attributes, as long as the callback routine can distinguish among them. after all, the attributes being passed can be checked for their name field, and the show() and store() routines can then act accordingly. the same thing can be said for device attributes in that same header file: ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf); ssize_t (*store)(struct device *dev, struct device_attribute *attr, const char *buf, size_t count); once again, the show and store routines are passed an attribute pointer so they can examine the name field of the attribute in question and act accordingly. but the same is *not* true for the bus class: ssize_t (*show)(struct bus_type *bus, char *buf); ssize_t (*store)(struct bus_type *bus, const char *buf, size_t count); note that these show and store routines *don't* incorporate an attribute pointer in the argument list, so you can't possibly define a pair of these routines that will properly process a number of attributes since those routines will have no idea how to distinguish between them, correct? here's an example from drivers/pci/pci.c: ===== start ===== static ssize_t pci_resource_alignment_show(struct bus_type *bus, char *buf) { return pci_get_resource_alignment_param(buf, PAGE_SIZE); } static ssize_t pci_resource_alignment_store(struct bus_type *bus, const char *buf, size_t count) { return pci_set_resource_alignment_param(buf, count); } BUS_ATTR(resource_alignment, 0644, pci_resource_alignment_show, pci_resource_alignment_store); static int __init pci_resource_alignment_sysfs_init(void) { return bus_create_file(&pci_bus_type, &bus_attr_resource_alignment); } ===== end ===== in the code above, a single attribute file, "resource_alignment", is created under /sys/bus/pci and, sure enough, it exists on my ubuntu system. but as you can see, the show() and store() routines associated with that file are absolutely hard-coded for that attribute only, and can't possible be used for any other attribute. is there a reason for this difference in design? if you look through <linux/device.h>, some of the attribute types (bus, driver) have show/store routines that don't take attribute pointers, while others (class, device) have show/store routines that *do*, allowing them to be more general. is this deliberate? and why? rday p.s. even when show()/store() routines take an attribute pointer and can switch among them, for the most part, the code doesn't seem to do that much, anyway. here's a perfect example from block/genhd.c, starting around line 922: static ssize_t disk_range_show(struct device *dev, struct device_attribute *attr, char *buf) { struct gendisk *disk = dev_to_disk(dev); return sprintf(buf, "%d\n", disk->minors); } static ssize_t disk_ext_range_show(struct device *dev, struct device_attribute *attr, char *buf) { struct gendisk *disk = dev_to_disk(dev); return sprintf(buf, "%d\n", disk_max_parts(disk)); } static ssize_t disk_removable_show(struct device *dev, struct device_attribute *attr, char *buf) { struct gendisk *disk = dev_to_disk(dev); return sprintf(buf, "%d\n", (disk->flags & GENHD_FL_REMOVABLE ? 1 : 0)); } ... etc etc ... note how those callback routines, given a pointer to the underlying attribute, ignore it completely, even when they're all related to an underlying "struct gendisk" and could have been written as a pair of large callbacks with a "switch" statement based on the attribute name. anyway, you get the idea. is there a reason for this difference? i may have more questions about this shortly as i read further. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

Invitation to connect on LinkedIn
by Amirali Shambayati via LinkedIn Oct. 10, 2012

Oct. 10, 2012

LinkedIn ------------ Amirali Shambayati requested to add you as a connection on LinkedIn: ------------------------------------------ Deepak, I'd like to add you to my professional network on LinkedIn. - Amirali Accept invitation from Amirali Shambayati http://www.linkedin.com/e/8z2206-h84uc46w-1x/L90NvsYL3GREvJdnM0f-HnfkWNbSD_… View profile of Amirali Shambayati http://www.linkedin.com/e/8z2206-h84uc46w-1x/rso/208904545/lYqo/name/494894… ------------------------------------------ You are receiving Invitation emails. This email was intended for Deepak Shah. Learn why this is included: http://www.linkedin.com/e/8z2206-h84uc46w-1x/plh/http%3A%2F%2Fhelp%2Elinked… (c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

1 0

getifaddrs() Byte Order of ifaddrs->ifa_addr.s_addr
by Pietro Paolini Oct. 10, 2012

Oct. 10, 2012

Hello, I am using the getifaddrs() function and when I do some computation with the IP Addresses contained in the ifaddrs struct seems these IP are in network byte order. Am I wrong ? Pedr0

1 0

/sys/block and SYSFS_DEPRECATED, wanting a little clarification
by Robert P. J. Day Oct. 9, 2012

Oct. 9, 2012

following through the code that creates the entire /sys hierarchy and ran across a puzzler involving /sys/block. here are the top-level entries in /sys: $ ls block bus class dev devices firmware fs kernel module power $ and it's easy to use a "grep" to see where most of them come from, assuming most of them are represented by a global variable name ending in "_kobj" as they often do: $ grep -r "_kobj = kobject_create_and_add.*NULL" * arch/powerpc/platforms/pseries/power.c: power_kobj = kobject_create_and_add("power", NULL); drivers/base/hypervisor.c: hypervisor_kobj = kobject_create_and_add("hypervisor", NULL); drivers/base/core.c: dev_kobj = kobject_create_and_add("dev", NULL); drivers/base/firmware.c: firmware_kobj = kobject_create_and_add("firmware", NULL); drivers/staging/speakup/kobjects.c: accessibility_kobj = kobject_create_and_add("accessibility", NULL); fs/namespace.c: fs_kobj = kobject_create_and_add("fs", NULL); kernel/ksysfs.c: kernel_kobj = kobject_create_and_add("kernel", NULL); kernel/power/main.c: power_kobj = kobject_create_and_add("power", NULL); $ but i didn't see the creation of /sys/block and, after a bit of looking, noticed it had a different name -- block_depr -- which doesn't look like it's used all that much: $ grep -rw block_depr * block/genhd.c:struct kobject *block_depr; block/genhd.c: err = sysfs_create_link(block_depr, &ddev->kobj, block/genhd.c: sysfs_remove_link(block_depr, dev_name(disk_to_dev(disk))); block/genhd.c: block_depr = kobject_create_and_add("block", NULL); include/linux/genhd.h:extern struct kobject *block_depr; $ now, given that that kobject is clearly "deprecated", it seemed that it should be configurable to not create it at all and, sure enough, there's what looks like the Kconfig entry in init/Kconfig: config SYSFS_DEPRECATED bool "Enable deprecated sysfs features to support old userspace tools" depends on SYSFS default n help This option adds code that switches the layout of the "block" class devices, to not show up in /sys/class/block/, but only in /sys/block/. ... but that looks a bit strange ... it doesn't omit the creation of /sys/block; rather, it omits the creation of /sys/class/block, which appears to be the *newer* location for that information. and there's this from drivers/base/core.c: ===== start ===== #ifdef CONFIG_SYSFS_DEPRECATED #ifdef CONFIG_SYSFS_DEPRECATED_V2 long sysfs_deprecated = 1; #else long sysfs_deprecated = 0; #endif static __init int sysfs_deprecated_setup(char *arg) { return strict_strtol(arg, 10, &sysfs_deprecated); } early_param("sysfs.deprecated", sysfs_deprecated_setup); #endif ===== end ===== anyway, i explicitly selected no SYSFS_DEPRECATED config settings in my build, but i still got the /sys/block entry under /sys. is it really necessary? if it's "deprecated", should one not be able to configure and build a kernel without it, if the newer(?) location for it is /sys/class/block? thoughts? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0