Communicate with an unknown usb serial device in linux

Hi all,
Recently I was trying to work with a 2D barcode scanner which was told to work as serial data device. When I inserted it in my linux system, there was nothing like a serial port or something in my "/dev" list. When I searched with the model number, I found nothing relevant to make it work. Usually it is suspected that the driver is not present in the system. I was really frustrated at that time since there was no lead and it had to be done soon. The material came with no driver. When I saw the syslog, it showed some path related to the device inserted. There I found information about the manufacturer and googled it which led me to a website where I found windows7 driver of this device. It felt like I was halfway there. I quickly downloaded the driver, installed and run it. And yes, I was able to view serial data after scanning 2D barcodes. But this wasn't it. It had to work on a linux system too.

As I tried to know more about the problem, I learned that there is a way. Writing a udev rule to control the usb device sounded like a cool thing to do. But the thing is, I had never written a udev rule and I was anxious to make the device work. So I kept searching around a bit and found something that said an unknown usb serial device can be recognized by the system if we load the kernel device driver with the product id and vendor id of the device. Finding product id and vendor id was easy. It is printed by "lsusb" command. So I gave it a try.

modprobe usbserial vendor=0x1eab product=0x0d02

I saw "dmesg" and there it was. the device was recognized as a serial device and found as /dev/ttyUSB0 .

Lesson: An unknown serial usb device doesn't need any extra driver but the usual usbserial driver can be used to register it in the linux kernel.

Microkernel approach in minix3

In computer science, a microkernel is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system. These mechanisms include low-level address space management, thread management, and inter-process communication (IPC).As an operating system design approach, microkernels permit typical operating system services, such as device drivers, protocol stacks, file systems code, to run in user space.MINIX3 has around 4,000 lines of code. Kernels larger than 20,000 lines are generally not considered microkernels.


Reflecting on the nature of monolithic kernel based systems, where a driver (which has approximately 3-7 times as many bugs as a usual program) can bring down the whole system,MINIX3 aims to create an operating system that is a "reliable, self-healing, multiserver UNIX clone".In order to achieve that, the code running in kernel must be minimal, with the file server, process server, and each device driver running as separate user-mode processes. Each driver is carefully monitored by a part of the system known as the reincarnation server. If a driver fails to respond to pings from the reincarnation server, it is shut down and replaced by a fresh copy of the driver.In a monolithic system, a bug in a driver can easily crash the whole kernel, something that is much less likely to occur in MINIX3.



Reliability factors in MINIX3 :-

Reduce kernel size
Cage the bugs
Limit drivers' memory access
Survive bad pointers
Tame infinite loops
Limit damage from buffer overruns
Restrict access to kernel functions
Restrict access to I/O ports
Reincarnate dead or sick drivers
Integrate interrupts and messages

Architecture :


The approach that MINIX 3 uses to achieve high reliability is fault isolation. In particular, unlike traditional OSes, where all the code is linked into a single huge binary running in kernel mode, in MINIX3, only a tiny bit of code runs in kernel mode about 4000 lines in all. This code handles interrupts, process scheduling, and interprocess communication. The rest of the operating system runs as a collection of user-mode processes, each one encapsulated by the MMU hardware and none of them running as superuser. One of these processes, dubbed the reincarnation server, keeps tabs on all the others and when one of them begins acting sick or crashes, it automatically replaces it by a fresh version. Since many bugs are transient, triggered by unusual timing, in most cases, restarting the faulty component solves the problem and allows the system to repair itself without a reboot and without the user even noticing it. This property is called self healing, and traditional systems do not have it.

UNSUCCESSFUL UBUNTU KERNEL UPGRADE TO 2.6.32-24

Hi all,
Just a month before 10.10 release,ubuntu 10.04 has created a problem for me.This post is more like a problem statement because I haven't figured out the solution yet.Last night I was upgrading my kernel to 2.6.32-24.After that my network manager was not running.I thought something was wrong with upgrade.So I rebooted and was shocked when I saw the grub menu.Previously, Grub menu used to show kernel versions 2.6.32-21, 2.6.32-22, 2.6.32-23 and their recovery options.Out of that 2.6.32-23 could not be used to boot.So,I used to boot through 22.But now,I could see only 23 and my system did not boot.when i tried to edit this option(generic kernel 2.6.32-23 in grub menu screen), I got first line as recordfail as shown in above image.

Then I tried to search on internet but found nothing important.Tried live cd of ubuntu 9.04 and tried to reinstall kernel.tried "sudo update-grub" and also grub-pc.Then checked /usr/src of 10.04 where I saw all previous kernel images along with 2.6.32-24.Now it looks like latest kernel couldn't be written but previous images were removed and only remained kernel is corrupt.So,I am not able to boot into ubuntu. Right now only solution is to reinstall 10.04.hoping a better solution from someone.