The following section applies to all hardware types. Some specifics with regard to scanner interface types are mentioned in the paragraphs at the end of this section.
Devfs, or 'device filesystem' has been an option in the Linux kernel since the late 2.2 series. If you haven't used it up to this point then I would suggest you at least consider it. It can immensely simplify device management. Devfsd, the device filesystem daemon, creates and removes devices on your system dynamically without the need for user input. You can tell if your system is running devfsd if you run ls -f /dev/ at the command line or in an xterm, and see mostly symlinks pointing to a device file, or "node", within a logically ordered hierarchy of subdirectories within /dev. You can also see devfsd running when you check running programs with ps -A at the command line. The daemon consumes very little memory. If you are running devfsd/devfs you can probably skip the following sections as the archaic process of creating device nodes will be done for you and it's simply a matter of finding the device by selecting the appropriate symlink in /dev.
If you want to give devfs a try, you need to enable '/dev file system' and 'Automatically mount at boot' in the 'File Systems' section of kernel configuration. Yes, it absolutely requires a recompile of your kernel if you don't have it in there already. WARNING: the only other supporting package required is 'devfsd' that you can obtain from your distribution vendor. WARNING: If you enable devicefs to automatically mount at boot-time without installing the devfs daemon you will be left with an unbootable system!
Devfs does not obviate the need to change permissions of devices for access by users.
Naturally the above comments about devfs are the opinion of your humble author (among others) and should be treated as just that, especially if you are a relative newbie or are not quite ready to compile your own kernel.
Beginning in the 2.6 series kernel devfs has been deprecated in favor of a userspace (i.e., non-kernel) daemon known as udev, though devfs remains as an option. You can find information on udev here if you are inclined to live on the bleeding edge.
If you aren't running devfs and devfsd, this is how it will need to be done, unless you are using libusb for a USB scanner, in which case you can skip this step and move on to Section 4. There are two ways to accomplish the creation of necessary devices manually. One is to use MAKEDEV and the other is to create the device nodes at the command line.
The MAKEDEV script is the easier of the two methods, the executable of which may be located in /dev or the usual places for storing binary executables (/bin,/sbin and so on). I direct you to man MAKEDEV, and would caution you to pay attention to the device-specific command options so that you can be sure the major and minor numbers are correct (see the next paragraph for more on this and why it is important, especially if MAKEDEV doesn't work or you prefer doing things the hard way).
A device can be created as a block (such as a drive), a fifo (file-in-file-out or pipe, as in xconsole) or a character device, which represents other hardware. Each device has a major and a minor number "coordinate" to tell the kernel what it is and where to access it. These numbers are not arbitrary.
If you are running a 2.4-series kernel you should consider becoming familiar with SCSI proc interface access, and whichever kernel you are running, you should read man sane-scsi before reading further. When the system boots up, generic SCSI device files are mapped on /dev/sgN, where N is a numeric value starting at zero. The major and minor numbers for SCSI devices are 21 and 0,1,2,3... respectively. You can find out what devices are loaded already with ls -l /dev/sg*, which should yield output similar to this:
You will need to make a /dev/scanner symbolic link to an existing device (for reasons clarified later). For example, if your scanner is connected to the first scsi-bus (and lun and target) of your SCSI host device, you should link it to the corresponding device:
Again, you can skip this step if using libusb. USB scanner devices have the major number 180 and minor 48, 49, etc., up to 63. First, check /dev to see what directory your distribution lays out its USB directory devices in, as some distributions might have these devices scanner0, scanner1...etc., within /dev/usb or as usbscanner0, usbscanner1... and so on, in the base /dev/ directory. If you find that in the /dev/ directory the scanner devices have already been made for you then your work is done. If not, you will need to create them yourself. As root, make a character device for your scanner like so:
...or if your distribution has a '/dev/usb' subdirectory:
Follow the example outlined in the above section to create the following generic parport devices:
You may also need to create /dev/port and/or /dev/parport depending on the backend you will use, so be prepared to return to this step if your application dictates it.
It is a good idea to be sure that your user account can access the device once all modules are loaded and device nodes created. The most security-conscious way to do that is to add scanner access to a particular group. On my system, the members of the group 'video' are allowed to use the scanner and other photographic devices. The way to accomplish this is to first change the ownership of the devices in /dev like so (as root):
...where root.video are the owner and group the device will now belong to. Obviously the specific command will vary by your system and the type of device, whether /dev/sg* on SCSI scanners, etc. It is important that you change the ownership of the device node itself and not the symlink; symlinks' ownerships are affected only by changing the parent devices or files they point to.
To see if your user account is a member of the group in question, as root issue the following command: grep -e video /etc/group. You should see something like the following:
...where '44' is the group number. Since no members follow the last colon in the 'video' group we can add them, let's say user 'jhs' with the command
After this it's simply a matter of allowing read and write access for the user in question of the device like so:
...where g+rw means add read and write access for group. See the documentation for chmod (man chmod or info chmod) for further info.