Messages in this thread | | | Date | Sat, 16 Oct 1999 11:00:09 -0700 (PDT) | From | ferret@phonewav ... | Subject | Re: [linux-usb] Re: USB device allocation (humour) |
| |
<warning> This post contains a humourous, semi-offtopic view of the latest flamewar. </warning>
On Sun, 10 Oct 1999, Horst von Brand wrote:
> Johannes Erdfelt <jerdfelt@sventech.com> said: > > No, no, no. No one seems to understand the issues at stake here. > > I have 2 modems, I plug modem A in first, it becomes (hypothetical) > > device /dev/modem1. I plug in modem B second, it becomes /dev/modem2. > > Now, I unplug both and plug modem B in first, it becomes modem1 now with > > the current naming system. > > > > This is completely unacceptable. > Worse yet, you plug in A, into socket 1 in wall. Plug in B, into socket 2 > in wall. Now permute all variables, throw in modem C as a replacement for A > which went south. How is the poor kernel going to know which modem device > goes where? > > Does devfs solve this problem right now? No. Will it be easy to solve > > this problem with devfs when an appropriate algorithm to name PnP > > devices is created. Yes. > But that mythical algorithm is impossible (see above).
<humour> Well... It might actually work, but the algorithm will require the use of two special CPU instructions not present in most (all?) modern CPU instruction sets: RUI (Read User Intention) and RAI (Read Administrator Intention), as well as a complex instruction removed from basic CPU archetecture when the CPU was invented: DWIM (Do What I Mean)
With the use of these special programming instructions (perhaps implimented on a special expansion module) the system will automagically reconfigure itself to match the user's wishes, play Bethoven's 9th symphony on the system fixed disk drives by modifying platter spin rates and head positioning paramaters, make toast, and wash dishes. </humour>
-- Ferret no baka
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |