February 2015 - kernelnewbies@kernelnewbies.org

wrapper device driver
by riya khanna Feb. 2, 2015

Feb. 2, 2015

Hi, I'm writing a device driver to to provide a wrapper device around a real device. Is it acceptable to do the following: wrapper_dev_open(flags) { // do additional bookkeeping real_dev_filp = filp_open(real_device_node_path, flags); } wrapper_dev_mmap(mmap_parameters) { // do additional checks return real_dev_filp->f_op->mmap(mmap_parameters); } wrapper_dev_ioctl(ioctl_parameters) { // do additional checks return real_dev_filp->f_op->ioctl(ioctl_parameters); } Is it safe to do something like this? what would be the caveats? Given a good use case, would the maintainers be willing to mainstream something like this? Thanks! -Riya

2 2

Question regarding strange-looking code in drivers/isdn/i4l/isdn_ppp.c
by Bas Peters Feb. 2, 2015

Feb. 2, 2015

Hi, I was checking some code in drivers/isdn/isdn_pp and came across the following: case PPP_VJC_COMP: if (is->debug & 0x20) printk(KERN_DEBUG "isdn_ppp: VJC_COMP\n"); { struct sk_buff *skb_old = skb; int pkt_len; skb = dev_alloc_skb(skb_old->len + 128); if (!skb) { printk(KERN_WARNING "%s: Memory squeeze, dropping packet.\n", dev->name); skb = skb_old; goto drop_packet; } skb_put(skb, skb_old->len + 128); skb_copy_from_linear_data(skb_old, skb->data, skb_old->len); if (net_dev->local->ppp_slot < 0) { printk(KERN_ERR "%s: net_dev->local->ppp_slot(%d) out of range\n", __func__, net_dev->local->ppp_slot); goto drop_packet; } pkt_len = slhc_uncompress(ippp_table[net_dev->local->ppp_slot]->slcomp, skb->data, skb_old->len); kfree_skb(skb_old); if (pkt_len < 0) goto drop_packet; skb_trim(skb, pkt_len); skb->protocol = htons(ETH_P_IP); } break; Could you explain to me why there are braces AFTER the printk invocation? Was it perhaps intended that the printk was included in the braces? I'm sorry if I'm missing something completely obvious here, but it seems kind of strange to me. With kind regards, Bas

5 5

Looking for ARM SoC porting guidelines
by Mike Thompson Feb. 2, 2015

Feb. 2, 2015

I'm working on a port the latest Linux kernel to a Nuvoton N32905 - a very inexpensive ARM9 based SoC similar to the Freescale iMX23 in many respects. My hope is that my code for this SoC will eventually reach the mainline kernel, but the whole process a fairly daunting task to a kernel newbie such as myself. I do have a six year old port of the 2.6.35 kernel to this SoC to help as a reference, but it's pretty much a rewrite to support devicetree, the common clock framework, and a myriad of changes needed to get a new SoC supported in the mainline kernel. Not to mention all the 2.6.35 code added for this chip isn't even close to the coding standards for the Kernel. So far I got the 3.17 kernel running pretty well the baseline peripherals such as clocks, interrupt controller, UART, GPIO & pin muxing along with hire level peripherals such as MMC/SD card support, MTD NAND and NOR flash and USB host support. As a guide, I've been using other ARM SoCs for examples and a number of very useful presentations on ARM SoC support from the Free Electron folks. Although presentations such as the "ARM SoC Linux Support Check-list" are very useful, they don't go into much detail. My question is two fold. Is there detailed information of all the things that need to be covered in the code to introduce a new ARM SoC into the kernel? Then, is there a description of how I start to go about contributing support for this chip into the Linux kernel? I honestly don't really know where to begin. Any advice or pointers would be sincerely appreciated. Mike Thompson BTW, my git reposity for this SoC is: https://github.com/mpthompson/linux/tree/n329

3 7

Re: Eudyptula Challenge response submission
by harshkdev Feb. 2, 2015

Feb. 2, 2015

Hi, You can use linux "script" command to save logging. It will save the logging in file named "typescript" in current directory. Regards Harsh Jain On 1 Feb 2015 00:11, Jonathan Jin <jjin082693(a)gmail.com> wrote: > > On Sat, Jan 31, 2015 at 11:56:31PM +0530, Alisha Jain wrote: > > > That said, in terms of proof, Little leaves it, to my understanding, > > > very much up to your personal judgment. > > > > Sorry, I didn't get you. > > What I meant is that the Eudyptula Challenge doesn't have any hard-fast > rules about exactly what constitutes adequate "evidence"; the admin > leaves it up to you to decide what kind of information to provide that > would be sufficient. > > One way to think of it: if you were the admin, and you were critiquing > a submission for the Task that you yourself are submitting for, what > would be enough to convince *you* that the implementation was correct? > > Be very critical of yourself; it is, to my understanding, hard to > overestimate just how critical kernel devs are. > > Do keep in mind, though, that I myself am also a newbie and that I am > also working through the Challenge, so do listen to everything I say > with the requisite grains of salt; hopefully more experienced members of > the mailing list can chime in as well. But I personally believe that > adopting this sort of self-critical mindset towards your work will pay > huge dividends later on. > > -- > Jonathan Jin > jjin.me > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies(a)kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

2 1

what should be a simple question about sysfs attributes ...
by Robert P. J. Day Feb. 1, 2015

Feb. 1, 2015

... but will take a while to set up. i want to write a short tutorial on kobjects, sysfs and attributes so i want to make absolutely sure i understand them (which is something i should understand anyway. :-) from sysfs.h and kobject.h, we have the definition of the generic kernel-wide "attribute" and "kobj_attribute" structures: struct attribute { const char *name; umode_t mode; #ifdef CONFIG_DEBUG_LOCK_ALLOC bool ignore_lockdep:1; struct lock_class_key *key; struct lock_class_key skey; #endif }; and 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); }; so what the above shows is that a "kobj_attribute" contains an "attribute" and has, as its internal callback routines, functions that deal only with completely generic kobject and kobj_attribute pointers. so if i'm creating a number of attributes for some kobject i've created, and i'm associating show and store routines with each one, those show and store routines must have that prototype. for example, look at mm/ksm.c and how the attributes and callback routines are defined -- here's one: //////// static ssize_t full_scans_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf) { return sprintf(buf, "%lu\n", ksm_scan.seqnr); } KSM_ATTR_RO(full_scans); static struct attribute *ksm_attrs[] = { &sleep_millisecs_attr.attr, &pages_to_scan_attr.attr, &run_attr.attr, &pages_shared_attr.attr, &pages_sharing_attr.attr, &pages_unshared_attr.attr, &pages_volatile_attr.attr, &full_scans_attr.attr, #ifdef CONFIG_NUMA &merge_across_nodes_attr.attr, #endif NULL, }; static struct attribute_group ksm_attr_group = { .attrs = ksm_attrs, .name = "ksm", }; //////// so the way i've always interpreted the above is that, when i finally register the attributes with the kernel, i am registering really just the underlying generic "attribute" structure and, when i try to access that attribute file, it automatically dereferences to the enclosing kobj_attribute structure to pick up the corresponding show() and store() routines associated with that attribute. so the first question is, is my understanding correct? if, in the above case, whenever i try to access one of the ksm attributes in /sys/kernel/mm/ksm, does the kernel take the reference to that *generic* attribute and automatically dereference/container_of() on it to get the enclosing kobj_attribute structure to pick up the corresponding show() and store() routines? asked a shorter way, is it assumed that a kobject attribute is *always* contained inside a kobj_attribute structure? and that the code in mm/ksm.c is an example of how to add individual show() and store() routines to such attributes? now here's part 2, and it's just a followup from the above. the second variation for attributes is what you see in cpufreq.c. rather than each attribute having its own callback routines, that code defines a prototype for cpufreq-*specific* show and store routines and a cpufreq-specific "freq_attr": struct freq_attr { struct attribute attr; ssize_t (*show)(struct cpufreq_policy *, char *); ssize_t (*store)(struct cpufreq_policy *, const char *, size_t count); }; *however* (and here's the thing i want to make sure i understand), when you register all of the cpufreq attribute files, each one still has to be interpreted as if it's part of a generic kobj_attribute structure with generic show() and store() routines, so what cpufreq does is define two generic show() and store() routines, and a couple helper macros that allow those two routines to then dereference to the appropriate cpufreq_policy and freq_attr pointers, then call the attribute-specific show() and store() routines: ////////// #define to_policy(k) container_of(k, struct cpufreq_policy, kobj) #define to_attr(a) container_of(a, struct freq_attr, attr) static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buf) { struct cpufreq_policy *policy = to_policy(kobj); struct freq_attr *fattr = to_attr(attr); ... snip ... } static ssize_t store(struct kobject *kobj, struct attribute *attr, const char *buf, size_t count) { struct cpufreq_policy *policy = to_policy(kobj); struct freq_attr *fattr = to_attr(attr); ... snip ... } ////////// and at the end of that file, the attributes are all registered with: static const struct sysfs_ops sysfs_ops = { .show = show, .store = store, }; static struct kobj_type ktype_cpufreq = { .sysfs_ops = &sysfs_ops, .default_attrs = default_attrs, .release = cpufreq_sysfs_release, }; which i interpret as saying that all of those attributes should be registered with the same single show() and store() routines (as opposed to ksm, which used different show() and store() routines for each attribute. in closing(?), as i understand it, when i access a kobject attribute file, it is assumed that that attribute is enclosed in a kobj_attribute structure, which contains the generic show() and store() routines, and i've seen two patterns for that: 1) in mm/ksm.c, each attribute is *directly* registered with callback routines with that prototype specific to that attribute, or 2) in cpufreq.c, all attributes are, in one operation, all registered with the *same* pair of generic callback functions, and those functions are then required to dereference the generic pointers to be able to call the appropriate callbacks for the given attribute. do i have this about right? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 3

Mount Compressed File like a Folder
by Lucas Tanure Feb. 1, 2015

Feb. 1, 2015

Hi, There is a way to mount a xz or gz file , update it, and umount ? Like, this file will be folder that is compressed and I can mount, update the files, and close ? Thanks -- Lucas Tanure +55 (19) 988176559

2 1