uSDE: User-space System Device Enumeration

Kernel

Október elején volt szó arról, hogy lassan búcsút mondhatunk a Linux kernelben levő devfs-nek, és helyét valószínűleg a Greg Kroah-Hartman által koordinált udev veszi majd át. Azért valószínűleg, mert ma felbukkant egy másik lehetséges alternatíva is. És egy kis flame kezd(ett) kialakulni ezzel kapcsolatban...

Mark Bellon - a Montavista embere - jelentette be ma a ``User-Space System Device Enumeration'' első publikus verzióját, amelyet a sourceforge.net/projects/usde oldalon lehet megtalálni. A uSDE (hasonlóan az udev-hez) függ a /sbin/hotplug-tól, a sysfs-től és ezek mellett még a /proc filerendszertől.A bejelentő szerint az uSDE sok szempontból hasonló az udev-hez. Greg Kroah-Hartman feltette a kérdést a bejelentőnek, hogy mi a probléma az udev-vel, miben más az uSDE mint az udev. Mi késztette a bejelentőt arra, hogy egy új, hasonló funkciójú implementációt fejlesszen ki. Greg KH megjegyezte, hogy az udev publikusan elérhető ez év áprilisa óta. Megkérdezte, hogy mi az oka annak, hogy egy teljesen új projektet indítottak az uSDE fejlesztői. Szerinte

sokkal ésszerűbb lett volna az udev fejlesztésébe beszállniuk.

Egyes fejlesztők szerint csak időpocsékolás volt az USDE-t párhuzamosan, titokban fejleszteni az udev-vel. Voltak akik azt mondták, hogy szólni kellett volna áprilisban (amikor Greg KH bejelentette az udev-et), hogy folyik egy hasonló projekt, mert akkor el lehetett volna dönteni, hogy melyik az életképesebb.

Grg KH szerint a projekt bejelentője már február-március körül beszélt az uSDE részleteiről. Gregnek a legnagyobb frusztrációt az okozza, hogy ha az uSDE fejlesztői úgy találták, hogy az udev valamilyen dologban hiányt szenved, akkor azt miért nem jelezték, miért nem segítettek a problémát megoldani, és ehelyett miért választották azt az utat, hogy titokban dolgoznak egy hasonló projekten.

John Cherry szerint szégyen, hogy két csapat dolgozott ugyanazon problémán egy időben. Megjegyezte, hogy jelenleg két implementációjuk van. Felvetette, hogy nézzék meg a felek a különbségeket/hibákat, üljenek asztalhoz, működjenek együtt és oldják meg a problémákat.

A thread itt.

( nevergone v | 2003. 10. 28., k – 23:49 )

Mondjuk tényleg kellemetlen, hogy két csapat dolgozik szinte ugyanazon... érdemes lenne egyesíteni az erőiket... :)

de az is lehet, hogy csak azt a szerencsetlen devfs implementaciot kellett volna normalisan

megcsinalni... mi ertelme van ennek? most valamelyik majd bekerul a kernelbe, aztan 1-2

ev mulva jon majd a kovetkezo, ami meg szebb, meg jobb? FreeBSD-n miert tudtak ugy

megcsinalni, hogy az egyszeri user eszre sem veszi, hogy az egesz /dev csak egy virtualis fs?

nem latok itt semmi flamet. olvass eheti fbsd hackers listat. erre ertettem.. kinek van commit bitje, kinek nincs, hanyan hagytak el duzzogva az elmult evekben a fbsd projektet, stb. az ilyen dolgok nem linux, freebsd vagy egyeb specifikusak. mindenhol vannak ellentetek, velemenykulonbsegek. ez igy van jol.

Én csak azt nem értem, hogy ennek a Greg KH-nak miért kell pattogni, meg a pálya széléről beszólni, hogy akkor most a két csapat üljön le, és egyesítség az erőiket, meg mittomén...

Ez számomra úgy hangzik, mintha jönne mondjuk dávid, vagy BalhiHB és azt mondaná, hogy irgumburgum lesz, ha nem ül le azonnal az MPlayer csapat meg a xine és nem csinálnak azonnal egy közös lejátszót...