> Does anyone else here card about these issues? Yes, we care. > Is the BeOS 5.0.3 implementation of addons good enough for OpenBeOS R1? Yes. The R5 devfs load and unload dynamicly kernel drivers, which themselves load and unload kernel modules as needed, and that works fine. And that's one of the finest feature of BeOS for drivers coders... Current OBOS devfs don't yet have these features, but he will. Binary compatibility :-) Now, let's try to answer your Linux kernel modules issue in a point of view of [Open]BeOS: 1) Well, our kernel too will need to have some built-in add-ons staticly linked, like PCI, IDE & BFS to be able to complete the boot process. All required drivers to be able to read/write from boot disk, in fact. But we'll be far from 7.4Mb here, I bet. 2, 4, 5 & 6) Under BeOS, drivers and modules can be reloaded at anytime, and are only loaded when needed. However, the ones open()'ed (aka, used!) at startup and not close()'d until shutdown can't be unload on-demand. Examples: PCI bus, IDE & SCSI, USB bus To add this feature will bring big issues... OpenBeOS will have same devfs behavior (it's not there yet, however). And it's a really usefull feature when you debug a driver/module. 3) I'm not sure to understand your issue here, but under [Open]BeOS the disk device name follow a single naming convention: /dev/disk/<bus_kind>/<bus_path>/raw, where: - <bus_kind> can be "ide", "scsi", "virtual", etc - <bus_path> are specific to each bus_kind. For "ide", it's always: /dev/disk/ide/{ata|atapi}/<bus_num>/{master|slave}/0/raw For "scsi", it's always: /dev/disk/scsi/<bus_num>/<lun>/<target>/raw That way, there is no 'detection order' side-effect. I guess it could still follow same convention for USB and FireWire disks... Unless you change the hardware bus layout (SCSI IDs, IDE channels layout, etc), the same device will get every time the same /dev/* path name. -Philippe