/dev had picked up a LOT of crud over the years,
for e.g. /dev/stdin. Is this a device, no it's process
specific so should be in /proc/self/stdin (this and
more is discussed in "a proc of shit".
Also all device files had to be present always (stored on disk),
which had a number of disadvantages, including:

    Major:Minor numbers (device IDs) had to be preallocated (a major problem :-)

    For embedded devices the inode storage was an issue

    There was no indication of what devices were actually on the system.

Other /dev/ prooblems include:

    Most non standard thing on the filesystem, which if not present would greatly
    simplfy umsdos and even allow NTFS to be used as the root filesystem.

    Whenever a device is used, an update of the atime (access time) is required. 
    Every update means a disk head seek, which reduces Linux disk performance,
    and has obvious power managment issues.

    The FSSTND (Linux filesystem standard document) suggests the possibility of a 
    read-only root filesystem. Read-only filesystems help reduce the chance that 
    mistakes, crashes, and crackers might damage something. Also specific devices
    like compact flash cards must not be written to too often, hence requiring a
    read-only root fs. The Linux root filesystem can not be read-only because the 
    normal /dev must be read-write to allow tty ownership changes. (This can be
    worked around in a kludgy way by linking /dev to a ramdisk (and putting some
    basic dev files in another directory).

The above problems are solved by devfs but there were many problems with it,
both in design and implementation.

For 2.5 the drivers are being consolidated into a hierarchy. I.E. instead of 
having a seperate list of PCI devices in the kernel for e.g., the PCI (and all) 
drivers will register with the global device tree. This can then be exported to 
userspace with driverfs like:

mount -t driverfs driverfs /proc/bus

Currently driverfs does not fully replace /dev or devfs, and only gives a
view of the currently connected devices on the system. It is envisaged
that it will replace these fully however (with the help of userspace
tools to deal with naming etc.)

driverfs files are named attribute pairs, where the name of the 
attribute is the name of the file, and the value is the contents.

Here's an e.g. branch of the driverfs tree:

SCSI controller-----------------------+
                                      |
 /devices/root/pci0/00:02.0/02:1f.0/03:07.0/bus1/id2/lun0/part1

The files can then be accessed directly using sed/cat/echo etc.,
or preferably using the devctl utility which gives more abstraction,
which will remove the burden of having intimate knowledge of the system 
configuration from the user. like hiding the location of the device tree, 
the meaning of every attribute, and the format for writing to each.

driverfs is going to be a huge improvment. For e.g. why is there
currently no /dev/eth/ directory so you can see which interfaces
are up/down etc. Currently the current code is the simplest way
to get the MAC address of eth0:

void mac_eth0(unsigned char MAC_str[13])
{
    #define HWADDR_len 6
    int s,i;
    struct ifreq ifr;
    s = socket(AF_INET, SOCK_DGRAM, 0);
    strcpy(ifr.ifr_name, "eth0");
    ioctl(s, SIOCGIFHWADDR, &ifr);
    for (i=0; i<HWADDR_len; i++)
        sprintf(&MAC_str[i*2],"%02X",((unsigned char*)ifr.ifr_hwaddr.sa_data)[i]);
    MAC_str[12]='\0';
}

Note this mightn't always work as the interface might not be present,
may have a different name than eth0. The general code is much more complex,
as you need to enumerate devices and iterate over them. Crazy stuff
(more on this in "a proc of shit").

Having a simple list of ethernet devices in dirverfs is way simpler,
and also has the advantage of being usable from scripts.

Other things driverfs will allow is to configure dirvers at runtime
whether they're modules or compiled in. Once all drivers use the generic
driverfs code, they can be configured dynamically say with a special file
called driver in the appropriate places in the tree.