On Wed, Oct 29, 2003 at 01:12:26PM +0800, Guo, Min wrote: > Here I try to summary out some difference for uSDE and uDEV,any comments are welcome! > In my opinion, competition is good and user can choose one they like because both of them > are user-space applications with a little minor kernel changes,is that right? > > 1.For the IDE/SCSI/PCI hotplug devices. > uDEV: What's with the wierd intercaps of the udev name? > edit namedev.config manually to specify certain map, > if slot change or device change, user can re-edit namedev.config Then use something that will not change if you move the device. Like a serial number, or other unique identifier. It's not udev's fault that you used a non-flexible rule :) Oh, and the file is called udev.config. > uSDE > record the id or slot at the first time, when move device to new slot or change to a new same type device, > automatically persist the name. > user can also specify map manually. > > 2.For non-hotplug device What do you mean by this? Memory devices? > uDEV: > not deal with it See Robert Love's very simple script to populate stuff from sysfs. It can run from initscript just like SDE. But in the end, udev will end up in initramfs and we will not need to do this. > uSDE > scan at boot time and also perform policy method. so when moved or replaced devcie when the machine is > down, the name can also be persisted. > > > 3. for multipath device. > uDEV > not support it. Not true. The CALLOUT rule handles this just fine. I have a small userspace program here from someone else that handles multipath devices through the CALLOUT rule. In fact I think this shows the flexibility of udev. If you come up with some new kind of device, or subsystem, or way of determining that you want to name a device, udev can run _any_ program to do this. No rebuilding the code, or creating a shared library. Small simple programs all talking together in a universal manner. Hm, where have I heard that design decision before.... > uSDE > automatically detect mulitpath device and create md device. support hot add a new path and remove a path. > > 4. ethernet > uDEV > not deal with it And this is on purpose. Why would we, when there are so many other programs out there that do deal with network devices. Remember, not all network connections are ethernet, which shows the limitation of SDE in not handling all of them (ppp, ipsec, usb network devices, isdn, atm, wireless, etc.) > nameif > name interface based on MAC, > uSDE > can set map based on MAC, SLOT. > support both setting manually map and automatic processing > support hotplug, eg. when exchange two device, the name can also be exchanged automatically. > . > 5.devfs simulation > uDEV > No such function Huh? All it needs is a single config file to be created. As the current installed base of devfs users can probably all fit into my basement with room to spare, and no one is coming up with such a file for udev yet, I don't think this is a real need yet :) But again, no rebuilding needed, if such a config file shows up, udev will do this just fine. > uSDE > provide devfs simulation method. > > >From the above comparsion, we can see uSDE really have some advantages.As far maintaince, > I think that more codes don't mean lacking maintainability. But it is at least one indicator, correct? > Thanks > Guo Min In the interest of full disclosure, Min is one of the SDE authors, and I am one of the udev authors. Min, maybe you can answer why Intel has spent effort on this project instead of offering to help udev, which has been public for a long time now? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
