Posts Tagged ‘linux’
atoi(getenv(“MYVAR”))
Posted in Technicalon May 28, 2008
These are mostly personal notes. I’m not sure if they will make sense to others.
I had a problem with a line of code like this:
int x = atoi(getenv("MYVAR"));
If this line was in daemon-ized code started at init level 2, it would segfault. (I’m not sure if these conditions are necessary, but those were my conditions).
getenv("UNKNOWN_VAR") == NULL
atoi(NULL) should == 0
But for some reason, things were segfaulting. I corrected the problem with:
if (getenv("MYVAR") == NULL) int x = 0;
else int x = atoi(getenv("MYVAR"));
- (2) Comments
- Tags: c, linux, programming, Software
Death by writing files from the kernel
Posted in Technicalon Mar 21, 2008
I’ve written my first semi-major Linux device driver. I won’t say exactly what it does other than write data out to hardware.
Generally, it is well NOT accepted to write to files from the kernel. If you ask how, people will tell you “don’t.” I completely agree with all of the reasons provided, but I decided to do it anyway.
The hardware I’m writing data to isn’t readily available. I wanted to be able to test my code well without having to have the hardware available. So I wrote in some non-release, non-production code that writes data to a file instead of to hardware, but only for testing purposes. When in this simulation mode, the user can interact with the driver and data gets written to the file instead of to hardware, and then the file can be checked for accuracy.
User writes to driver -> kernel driver handles write -> driver writes to file
Easy enough? I thought so until I tried writing to the driver as a regular system user. I chmod’ed the driver so that the user had full privileges to read and write to the file. When root would write to the driver, everything worked, when the regular user would write to the driver, the kernel would crash.
The problem was that the user didn’t have write permissions to the test file that the driver was writing to. I thought the kernel level driver could write to any file it wanted, but apparently, the user’s permissions to the file permeated through the kernel driver. Changing the files permissions fixed things so they didn’t crash any more.
The caps lock and scroll lock lights blink on the keyboard when the kernel crashes. Not quite fireworks, but still kind of cool. Development in a virtual machine is key, so that you really don’t crash your computer, just the virtual machine.
- No Comments
- Tags: linux, Software Engineering
AverTV Media on Ubuntu
Posted in Technicalon Aug 25, 2007
I have an old TV tuner card that I picked up in 2002. I can’t remember exactly what type of card it is, but after searching around the internet, I’m somewhat convinced that it is the AverTV Media (with FM tuner). The card identifies itself as an AverTV Phone something or another, but I know it isn’t any of their “phone” variety of cards.
Read the rest of this entry »
- No Comments
- Tags: Hardware, linux, tv
Keeping Linux under Ctrl-Ctrl
Posted in Technicalon Jun 28, 2007
Recently, Google released their Google Desktop product for Linux. I found out about it just this evening. Earlier today, I was searching through my home directory looking for some old files from a long time ago, and I though, “Wouldn’t it be great if Google Desktop Search was available for Linux?” About two hours later, my wish came true.
Read the rest of this entry »
- (1) Comment
- Tags: Google, linux
Upgrading operating systems
Posted in Technicalon Apr 20, 2007
How would you respond if I told you that all it would take is a few clicks to upgrade your Windows XP to Wndows Vista? That it would be able to download and upgrade the entire system in a matter of hours (depending on the speed of your Internet connection). What if I said it would also upgrade your word processor, web browser, and most of the other commonly used applications? What if I said it wouldn’t even cost you a thing?
- No Comments
- Tags: linux
Drag and drop into Konsole
Posted in Technicalon Feb 2, 2007
I found a very cool thing today. I use KDE on Linux. One of the things I like best about KDE is that it supports psudo- filesystems such as fish, which allows you to access a remote filesystem over ssh. I wanted to copy a file that was on a remote system into a local directory. Without thinking, I did the mouse drag-and-drop action to move the file. Except that I dropped the file into Konsole, the KDE terminal program. A popup menu appeared with several options, one of which was ‘cp’ which I selected. The result was that the file was copied from the remote server to the current working directory in my KDE terminal. My terminal showed that it had run a command in order to copy the file, which was:
kfmclient copy ‘fish://username@remoteserver.com/tmp/filename’ .
This is extremely cool, and I’m definately going to have to use it a little bit more often.
- (1) Comment
- Tags: linux
Greg Kroah-Hartman came to my Open Source Software Engineering class today. Here are a couple of interesting thoughts that I’ve been able to gather from his presentation:
- New patches are tested with Andrew’s mm kernel, and if they work out, then they are sent to Linus’ kernel.
- Time between kernel versions should be about two months.
- 1475 unique contributors in one year alone
- Grew kernel 6% in one year
- 2.6.18.y kernels are bugfixes only
- Powerful to have a set list of rules so it is easy to say no to people
- Day job: in charge of all SuSE kernel developers. All work remotely around the world.
- Distros like to maintain an enterprise kernel for up to 7 years, which is crazy
- E*Trade uses Gentoo because they can control it.
- Modular kernel which little interconnectedness which makes it easy to have module maintainers who don’t
- Tools: git, quilt, sparse
- Linus’ main job: say no
- Linux isn’t developed, it evolves. This means that there really isn’t a firm development plan.
- Can’t go by time anymore with git
- Signed-off-by is a blame path which create a reputation based system for submitting patches
- The IDE module guy three times has gone crazy
- Contributors have to defend their code
- No development tree makes the engineering process more careful. Things have to evolve gradually with small changesets.
- All the drivers are in the tree. This means that if you change an API function, then you can go and change all the drivers that use that API just like that.
- People who work on open source projects are much more likely to get jobs, because you have currently shipping code.
- Learn about licenses, they are very important.
- Xen is a good example of running an open source project the wrong way. There are political and social reasons why.
Status Updates
- appspot.com domain) for free.
Recent Comments