You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

While reviewing my CUPS logs today I noticed that a bunch of printer devices are loaded by CUPS:

/dev/ttyS0 through /dev/ttyS31/dev/usb/lp0 through /dev/usb/lp15

I suspect CUPS is merely reading the device list from /dev.

I'm running some old boxes here. One box has only two USB ports and IIRC they are USB 1.0. The other box also has two USB ports but I think they might be USB 2.0 compatible, although I am unsure because I never use the ports.

I don't have any USB devices here and I likely am not going to have any for these boxes. My only two external peripherals are a parallel port printer and a parallel port scanner. But even if I did opt for some USB devices I only have two ports, not 16.

I also surely do not have 32 serial ports available on either box.

I'm thinking I'd like to disable the overhead attached with all of these extra devices. I'm unfamiliar with all there is to know about the /dev file system and I'm wondering whether I'll be okay if I simply delete all the unnecessary devices. Or perhaps, is there an easier way to disable them from within a config file? Or do I need to recompile the kernel?

I suspect that the unnecessary devices probably produce no impact per se on my boxes, but with old hardware every little tweak seems to always help---even if only mentally .

If you remove /dev devices you have a good chance of breaking your system in the process. If you are lucky enough not to break your sysytem you still haven't gained much except an uncluttered /dev directory. I would leave them well alone, they're not hurting anyone

And yes, if you upgrade to a udev capable kernel you will get much fewer unused device listings.

you can compile support into the kernel as modules, leaving them unloaded until you need them..or taking out support for them entirely.

The devices wouldn't even be created (at least that seems logical to me). I don't believe ttysx has anything to do with the parallel port (which is /dev/lpx), if I'm not mistaken. You can set serial support modular as well if you wish..

[EDIT] BAD idea to start removing stuff from /dev/ ...

part of having root privledges is being able to break things..the system is trusting YOU to know what you're doing. Do the research before deleting random files

(I'm talking in general here..not specifically to you anymore - you came to a forum, good choice)

When you recompile the kernel and enable udev, you will mount a ramdisk on top of /dev. So all your device files will still exist on your actual disk, it's just that you won't be able to see them. And instead of getting a massive list of possible devices, you will only see a list of devices actually exported to userland from the kernel. Another dependency is the hotplug scripts, available from ftp.kernel.org. When you plug in a new device (e.g. a USB mouse or keyboard or thumbdrive), that will show up (if everything is configured correctly) in the /dev directory magically. But, as with all software, the best rule of thumb is that if it ain't broke, don't fix it. And it seems like everything is working for you.

Upgrade to 2.6 as well because that will enable udev support and eliminate lots of unused /dev entries.

For myself, I'm no kernel guru and I have no desire to become one. Recompiling is okay and I've done that to provide the 2.4.x kernel I need/want for my old boxes. I don't do RAID, LVM, and a slew of other things my older boxes do not support. I don't even use the hotplug rc.d script because there is no need. My boxes are "old," static, and to many young folks and bleeding edge types, just plain boring.

I still use the 2.4.x kernels and likely I will not change until after P.V. officially sanctions the 2.6.x series. The simple reason is I have other things to do. I realize many people use 2.6.x without problems, but I've read contrary stories too. With my old boxes, 2.4.x works just fine.

Quote:

If you remove /dev devices you have a good chance of breaking your system in the process.

This is something I suspected. Possibly long ago in a galaxy far away I once tried this and my subconscious is reminding me not to go there and hence, I posted my question here instead.

Quote:

And instead of getting a massive list of possible devices, you will only see a list of devices actually exported to userland from the kernel.

Can I do this with the 2.4.x kernel? Been a while since I recompiled my current kernel.

Quote:

And it seems like everything is working for you.

Yes, everything works, no complaints, just curious about ways to reduce the "clutter." That all of these unnecessary devices are created seems wasteful to me and if there is a way to reduce that clutter with the 2.4.x kernel then I'd be grateful to know.

udev is a new device management system available to the 2.6 kernel series. I believe devfs has been deprecated..

essentially is nicer and newer. I have yet to have ANY problems on my system with any 2.6 kernel. Overall there is a noticable difference in performance between 2.4 and 2.6..things are a bit "cleaner".

Quote:

For myself, I'm no kernel guru and I have no desire to become one. Recompiling is okay and I've done that to provide the 2.4.x kernel I need/want for my old boxes. I don't do RAID, LVM, and a slew of other things my older boxes do not support. I don't even use the hotplug rc.d script because there is no need. My boxes are "old," static, and to many young folks and bleeding edge types, just plain boring.

I don't think you have to be any guru to compile your kernel, though one should be educated. I believe compilng the kernel is part of the essence of linux and unix in general. You have the power to set it up as you wish, you can tailor the system to your needs. I'm no young "ricer" though I take pride in my system and how it runs. I guess it's also about expanding my experience.

Well anyway..compiling a new kernel - or rather tailoring a kernel to your needs - is not all that difficult, but it's pretty damn beneficial in the long run. Good luck.