Driving Me Nuts - Things You Never Should Do in the Kernel
In conclusion, reading and writing a file from within the kernel is a bad, bad thing to do. Never do it. Ever. Both modules from this article, along with a Makefile for compiling them, are available from the Linux Journal FTP site, but we expect to see no downloads in the logs. And, I never told you how to do it either. You picked it up from someone else, who learned it from his sister's best friend, who heard about how to do it from her coworker.
Resources for this article: /article/8130.
Greg Kroah-Hartman is one of the authors of Linux Device Drivers, 3rd edition and is the kernel maintainer for more driver subsystems than he likes to admit. He works for SuSE Labs, doing various kernel-specific things and can be reached at greg@kroah.com for issues unrelated to this article.
- « first
- ‹ previous
- 1
- 2
- 3
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Build a Skype Server for Your Home Phone System
- Validate an E-Mail Address with PHP, the Right Way
- Why Python?
- A Topic for Discussion - Open Source Feature-Richness?
- Tech Tip: Really Simple HTTP Server with Python
- Great
1 hour 18 min ago - Reply to comment | Linux Journal
1 hour 26 min ago - Understanding the Linux Kernel
3 hours 41 min ago - General
6 hours 11 min ago - Kernel Problem
16 hours 13 min ago - BASH script to log IPs on public web server
20 hours 40 min ago - DynDNS
1 day 16 min ago - Reply to comment | Linux Journal
1 day 49 min ago - All the articles you talked
1 day 3 hours ago - All the articles you talked
1 day 3 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




Comments
I think there is a typo on the write code...
I think there's a typo on the final write code. The first call after checking for the file descriptor should be vfs_write and no the sys_write call.
fd = sys_open(filename, O_WRONLY|O_CREAT, 0644);
if (fd >= 0) {
vfs_write(fd, data, strlen(data));
about usb drivers
I am writing usb device driver and i want some help.
OS that i am using is suse10.2. If i write down complete usb driver that is mentioned in your documents, what are the extra things that i need to do apart from inserting that module in to kernel (insmod).If i insert my usb driver module in to kernel how can we stop kernel from using previous usb driver and now kernel should use the driver(module) that i have inserted.
Similarly i have also written mouse device driver for ps2 mouse.But i faced the simiar problem.How we should tell to kernel that dont use previous driver for mouse use that i have inserted.
Please Help Me.If i could get way for this i will be able to run both the drivers.
Yeah, the kernel has
Yeah, the kernel has internal API to open files: filp_open(), filp_close(), vfs_read(), ...
Consult for example with sound/sound_firmware.c.
In proprietary spec I have
In proprietary spec I have
int ioctl(int fd, int req=DMX_SET_SOURCE, int *frontend_fd);
where frontend_fd is the pointer to file descriptor of another driver opened previousely.
The logic here - the user is responsible for which driver to connect for internal communication
Anyway I need sys_ioctl to call one driver from another. I can not parse user file descriptor to determine which driver I need.
Don't use sys_*()
If you do read/write files from the kernel, then please do it without too much hacks, meaning you use
filp_open,vfs_readandvfs_writeinstead ofsys_open,sys_readandsys_write, respectively. Thanks!Hey you said that you can
Hey you said that you can use filp_open , vfs_read and vfs_write. I tried that but I could not write and read into the file.
static void write_file(char *filename, char *data)
{
struct file *file;
file = filp_open(filename, O_WRONLY|O_CREAT, 0777);
ssize_t wc;
wc = vfs_write(file, data, strlen(data),0);
if(wc < strlen(data))
{
printk(KERN_INFO "Problem in Writing Data\n");
}
filp_close(file,0);
}
This is my code.
Please let me know where I am wrong.
Thanks,
Translation
Wow... Can someone translate this into English for me?
How very clever
Greg: thanks for this summary. And how clever of you to obscure your advice concerning file writes from kernel space by including the sys_write() call in your sample, misdirecting readers into ignoring the vfs_write() and thinking that they would still need that syscall.
err
Your final example still uses sys_write and the snippet above that has a syntax error in it.
Kernel
God, I hate re-writing kernels. I used to use suse linux. Everytime I had to get my wireless card to work, I would have to re-write the kernel and that shit takes forever.
Rides and Whips
Clearly, you know a lot
Clearly, you know a lot about linux. You don't re-write a kernel. You recompile it with drivers or code for your device. If you were rewriting a kernel that shit would take forever. Recompiling a kernel takes me only a few minutes on my machine, granted, it's faster than most. Keep anti-linux comments on topic and try to back them up with fact. The simple fact is, you don't need to make any thing up to criticize any operating system, there is plenty wrong with any given one to be criticized.
You had to re-write the
You had to re-write the kernel everything you wanted your wifi card to work?
vince
everytime*
everytime*
Not using sys_write
"how this can be done by not using the sys_write call"
But you've used it right there!
Stacked Drivers Concept
I know one case when this is the cleanest practical solution.
Linux kernel is supposed to be build on "stacked drivers" concept. In reality, kernel supports it in very limited number of specially designed core drivers. Try to write a translation driver for a device which already has a generic driver. Good example is having a USB-to-serial chip talking to a custom hardware. Now, anyone trying to create a driver for that custom hardware is facing a huge uphill battle with the kernel, unless you can just open device file created by generic driver and talk to it in vfs. However, vfs_read/vfs_write are user-space restricted. (Unacceptable alternatives: user-space daemon, full-blown rewrite of USB-to-serial driver, etc.)
Using technique in this article proves to be the only way for given situation.
You've failed to explain why
You've failed to explain why you can't solve the problem in userspace in your example.
What's wrong with a libmycustomhardware.so?
Problem with sys_write and sys_open
hi,
information given in this article is very useful.
i have tried above codes on kernel 2.6.9, but getting error with sys_open and sys_write.
it gives error in system log file:
fileops: Unknown symbol sys_open
fileops: Unknown symbol sys_write
Please suggest me how can i overcome this problem.
I welcome your suggestions.
Thank you
dont use sys_read or
dont use sys_read or sys_write or sys_open or sys_open calls.. instead u can use vfs_read, vfs_write, filp_open, filp_close calls..
don't do that!
don't do that!
(sorry)
I think using sys_open and
I think using sys_open and sys_read is more general than vfs_open vfs_read. In my case, I need to create to module to read a file from SD card (fat), vfs_read always give me many errors.
In thread
Could this function be called by Thread ?
Used this to interface a stack with the DVBS drivers of Linux
Used this to interface a stack with the DVBS drivers of Linux.
Good Job!!
Hope to see you in person some day!!!
i guess filpopen should work
i guess filpopen should work ...
Did u look into copyfromuser() and copytouser()
These are useful for getting data back and forth between kernel and user space.
netlink sockets are the very
netlink sockets are the very efficient way to communicate between user, kernel modules and vice-versa.. Its very easy to use also..