May 2011 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

utrace status
by Sudheer Divakaran May 6, 2011

May 6, 2011

Hi List, I was experimenting with the latest version of systemtap's facility for debugging userspace applications, for that the kernel must be compiled with CONFIG_UTRACE=y option. Looks like the original source path (http://people.redhat.com/roland/utrace/) is no longer available. The description about utrace can be found at http://lwn.net/Articles/224772/ Any idea about its current status. Is it discontinued? TIA -- Thanks Sudheer

1 0

two questions about test_and_clear_bit()
by Parmenides May 6, 2011

May 6, 2011

Hi, For the following function, I have two questions: static inline int test_and_set_bit(int nr, volatile unsigned long * addr) { int oldbit; __asm__ __volatile__( LOCK_PREFIX "btsl %2,%1\n\tsbbl %0,%0" :"=r" (oldbit),"+m" (ADDR) :"Ir" (nr) : "memory"); return oldbit; } 1. There are two instructions in the inline assemably, namely btsl and sbbl. But, can the only one LOCK_PREFIX ensure that the operation is atomic? 2. The clobber list of the inline assembly contains a string of "memory". What is the meaning of this declaration and why does the operation need it ? After all, some other operations such as clear_bit() dose not need "memory" indeed. The declaration of "memory" appears in source code of kernel here and there, and bothers me for a long time. So any details about it will be appreciated. static inline void clear_bit(int nr, volatile unsigned long * addr) { __asm__ __volatile__( LOCK_PREFIX "btrl %1,%0" :"+m" (ADDR) :"Ir" (nr)); } Thanks!

1 0

Clarification regarding design of a device.
by mindentropy May 5, 2011

May 5, 2011

Hi, I have say a crypto device and if I pass a data stream assuming echo "test" > /dev/aes and when I read it I get an encrypted output. Now if a program opens the same device twice should and pass different streams should I differentiate those 2 streams and have encrypted buffers of these 2 streams as output? If yes how should I differentiate it? Or should I not differentiate and provide different devices say aes0,aes1 or should the userspace program worry about locking and sharing of resource? Thanks.

2 4

question about misc char devices, and relationship with udev
by Robert P. J. Day May 5, 2011

May 5, 2011

(probably a question with a very simple answer, i just don't know what it is.) i'm currently trying to document the use of the "misc" char driver to quickly and conveniently create a character driver. there's a decent explanation of misc drivers in the book "essential linux device drivers", as well as a nice example here: http://virtlog.com/2008/03/25/linux-miscdevice-sample/ but here's where i get confused. what a misc char driver does is combine a lot of what you'd normally do in creating a regular char driver in a single call. on page 160 of ELDD, it's explained that a single call to misc_register() does all of the following that you would normally have to do yourself for a regular char driver: * allocates major/minor number via alloc_chrdev_region() * creates /dev and /sys nodes via call to class_device_create() * registers itself as a char driver using cdev_init() and cdev_add() sure enough, i compiled that sample misc char driver (called "mymisc"), loaded it and got an entry for that module both under /sys and under /dev, where i now have the device file: crw------- 1 root root 10, 56 2011-04-23 08:18 /dev/mymisc but here's the confusing part. who or what created that /dev entry? i always thought that was the job of udev, but i never added any udev rule for this new driver. so how did that new /dev file come to be? is there some sort of generic udev rule that would have handled this? also, the ELDD book claims that misc_register() calls the kernel routine class_device_create(). i'm looking at the entire kernel implementation for misc drivers in drivers/char/misc.c, and what i see is a call to device_create() instead. i suspect i should start following the flow of control here, but i'm still curious as to how that /dev file came into existence without any obvious help from udev. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

3 2

Re: Confusion in kobjects
by Vikram Narayanan May 4, 2011

May 4, 2011

> On Wed, May 04, 2011 at 07:26:44PM +0530, Vikram Narayanan wrote: >> The kernel doc (kobject.txt) says that >> >> "No structure should EVER have more than one kobject embedded within it. >> If it does, the reference counting for the object is sure to be messed >> up and incorrect, and your code will be buggy. So do not do this. " >> >> But in the file drivers/uio/uio.c, a structure has two such kobjects. >> >> struct uio_device { >> struct module *owner; >> struct device *dev; >> int minor; >> atomic_t event; >> struct fasync_struct *async_queue; >> wait_queue_head_t wait; >> int vma_count; >> struct uio_info *info; >> struct kobject *map_dir; >> struct kobject *portio_dir; >> }; >> >> So, What is the exception for this structure? Is this right? If yes, >> can someone explain why it is right, and where should we use it? > > There are not more than one kobject _IN_ the structure. It merely > has pointers to more than one kobject (three actually), which is fine to > do. Thanks for the clarification. Think I have to go for an eye checkup ;) Thanks, Vikram

1 0

registering a character driver without cdev_init()/cdev_add()
by Robert P. J. Day May 4, 2011

May 4, 2011

continuing my perusal of various character drivers under drivers/char/ to find good examples for an intro class, i notice dsp56k.c, whose init routine contains the snippet: ===== start ===== if(register_chrdev(DSP56K_MAJOR, "dsp56k", &dsp56k_fops)) { printk("DSP56k driver: Unable to register driver\n"); return -ENODEV; } dsp56k_class = class_create(THIS_MODULE, "dsp56k"); if (IS_ERR(dsp56k_class)) { err = PTR_ERR(dsp56k_class); goto out_chrdev; } device_create(dsp56k_class, NULL, MKDEV(DSP56K_MAJOR, 0), NULL, "dsp56k"); printk(banner); goto out; out_chrdev: unregister_chrdev(DSP56K_MAJOR, "dsp56k"); out: return err; } ===== end ==== so rather than the canonical combination of cdev_init() and cdev_add(), this appears to register the pre-defined DSP56K major number, then goes straight to registering the driver with sysfs. is this now an alternative way of registering character drivers, if you want to register them with sysfs as well? as i read it, device_create() will create the /dev file so is this just a newer way to register character drivers? i don't think i've run across any other drivers that have this structure but, then again, i haven't been looking that hard. yet. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

3 3

how to see the minor numbers allocated to a driver?
by Robert P. J. Day May 4, 2011

May 4, 2011

something i was curious about way back when -- given that register_chrdev_region() and alloc_chrdev_region() allow one to specify a range of minor numbers desired that doesn't necessarily have to start at zero, is there a way from user space to see what those numbers are after the device registration is complete? obviously, looking at /proc/devices will always give you the major number, that part's easy. and if you look at fs/char_dev.c, it's the chrdev_show() routine that prints each major number and its registered name: === void chrdev_show(struct seq_file *f, off_t offset) { struct char_device_struct *cd; if (offset < CHRDEV_MAJOR_HASH_SIZE) { mutex_lock(&chrdevs_lock); for (cd = chrdevs[offset]; cd; cd = cd->next) seq_printf(f, "%3d %s\n", cd->major, cd->name); mutex_unlock(&chrdevs_lock); } } === if it's a "misc" driver, then you already know that it's major number is 10, and the contents of /proc/misc will give you the single minor number allocated for it. but if, for some (bizarre) reason, you don't know what minor numbers the driver will try to allocate, is there a way to tell what they are after the fact? or is this just a silly question? rday p.s. for fun, a while back, i extended the chrdev_show() routine to append to each line the range of minor numbers that had been allocated, so that each line would read: #### name [a-b] i didn't have a compelling reason for that, i was just curious. and it occurred to me that if userspace programs parse that file for the first two fields, then having extra info at the end of each line might not be that disruptive, especially if adding it was a kernel config option. or maybe i'm making too much of this. -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 1

Confusion in kobjects
by Vikram Narayanan May 4, 2011

May 4, 2011

The kernel doc (kobject.txt) says that "No structure should EVER have more than one kobject embedded within it. If it does, the reference counting for the object is sure to be messed up and incorrect, and your code will be buggy. So do not do this. " But in the file drivers/uio/uio.c, a structure has two such kobjects. struct uio_device { struct module *owner; struct device *dev; int minor; atomic_t event; struct fasync_struct *async_queue; wait_queue_head_t wait; int vma_count; struct uio_info *info; struct kobject *map_dir; struct kobject *portio_dir; }; So, What is the exception for this structure? Is this right? If yes, can someone explain why it is right, and where should we use it? Thanks, Vikram

2 1

Faking PCI devices?
by Manohar Vanga May 4, 2011

May 4, 2011

Hi, I have written a simulated driver for a PCI board and am looking for a clean way to use the driver. Currently, I am setting the PCI ids to PCI_ANY_ID and only allowing a single probe call to go through using a global variable (concurrency issues but I don't care for the simulation). static int n ... static int fake_board_probe(struct pci_dev *pdev, const struct pci_device_id *ent) { if (n == 1) return -1; n = 1; ... } static int fake_board_init(void) { n = 0; .... } I want to do a cleaner job of this and wanted to write a PCI bridge driver that actually registers the devices with the correct IDs that I need. This also gives me the advantage of being able to register multiple devices which is a useful for the simulation I am working on. Can anyone point me in the right direction for this? Most of the code (eg. struct pci_controller) seem to be architecture specific. The code is available for anyone interested at: https://github.com/mvanga/wbonesim Thanks and best regards. -- /manohar

2 1

Question on hd_geometry & blk_rq_cur_sectors
by Vic May 4, 2011

May 4, 2011

Hi All, I have 2 questions on creating a ramdisk driver. How do I init the hd_geometry for my device ie to say how do I set geo cylinders, head, sectors and size. As this is ramdisk I dont think it matters but want to confirm. geo->cylinders = 1; geo->heads = 1; geo->sectors = Device.size/logical_block_size; geo->start = 0; Also, with my current settings, if I use DD on my ramdisk I get "blk_rq_cur_sectors" count to be always 8, which confuses my drive b'se I want to only handle 512 requests at a time. Simple command to test the disk sing DD "sudo dd if=/dev/urandom of=/dev/sbd0 bs=512 count=1" with bs=512 I was hoping to see only the 512 byte request

2 1