ANNOUNCE: User-space System Device Enumeration (uSDE)
Quoted 4 lines
How does uSDE relate to udev? You do not mention it in your email, though it claims to implement similar, if not identical functionality. Is it related? Is it built on top of it?
The uSDE is not built on top of udev.
The uSDE and udev are similar in some respects. They both create device nodes. There is a lot more to handling devices than managing device nodes.
Some differences between uSDE and udev that come to mind as I type (a good deal of this is part of the INTRO in the uSDE tarball):
Devices are classified and an explicit, ordered list of policies are invoked on behalf of the devices based on that classification.
Policies are implemented as open plug-ins that have complete control (e.g. naming, configuration, special needs) over a device.
Multiple policies can be executed concurrently; they can be independent or cooperative.
All device types are embraced - ethernet, disks, cdroms, floppies, MD, LVM and so on. Policies can analyze data and handle complex situations such as ethernet interface anchoring, multiported disk handling and automatic multipath device management.
The concept of service agents who provide critical information to the enumeration framework allowing policies to handle extremely diverse hardware situations such as multiple chassis and geographical addressing.
The uSDE sample policies implement basic device replacement and relocation strategies, something that the community has been asking about for some time.
If you want to learn more about that differences, download the tarball and try it out...
The uSDE was built in response to a set of telco and embedded community requirements. We found it difficult to express our ideas. Everyone wanted to see code and documentation. Here is the code and the initial documentation. This is a starting point...
Quoted 2 lines
If not, are you planning on merging your efforts with udev in the future?
It is to everyone's advantage to converge on an implementation of enumeration that meets all of the requirements.
Quoted 3 lines
Are you using the libsysfs library for accessing sysfs data? If not, I highly recommend it.
The uSDE is not currently using the libsysfs library. The project will look into this in the near future.
Patches gladly accepted. :)
Quoted 7 lines
I would also recommend sending email to the linux-hotplug list, as most of the hotplug-related applications are discussed and developed via that list.
Pat
Thanks, I'll copy them.
mark
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines · Mark Bellon
The uSDE was built in response to a set of telco and embedded community requirements. We found it difficult to express our ideas. Everyone wanted to see code and documentation. Here is the code and the initial documentation. This is a starting point...
Quoted 2 lines
If not, are you planning on merging your efforts with udev in the future?
It is to everyone's advantage to converge on an implementation of enumeration that meets all of the requirements.
What are your requirements, and why does udev not meet them? Is there some major disagreement between what udev does, and what you want to do? If so, what?
udev has been out in the world since April, any reason for not helping out with the existing project instead of going off and starting your own? It's not that I mind competing projects, it's just that I don't see your reasoning as to why there needs to be two different ones.
thanks,
greg k-h
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines
The uSDE was built in response to a set of telco and embedded community requirements. We found it difficult to express our ideas. Everyone wanted to see code and documentation. Here is the code and the initial documentation. This is a starting point...
I find it difficult to see your justification for designing a project from scratch instead of contributing your time, effort, and ideas to a pair of already existing, albeit immature, projects that do exactly the same thing.
Please note that I'm not trying to incite yet another device naming flame war, but you have to understand how frustrating it is to see you guys make the same mistakes over and over, ad inifitum.
Let's review. SDET was posted several months ago by the Montavista telco group as a 2.4 solution that was driven by customer requirements. So be it.
In the last year, you (and/or your group) has posted several proposed device naming solutions; each of which were shot down because of over-design, misdirection, or simply tastelessness. Each time we encouraged you to align yourselves with the overall design goals or simply contribute to existing projects.
Personal contact in Ottawa resulted the same message. IIRC, many if not all, of the atttending MV telco engineers even saw Greg's talk on udev.
In the time since, you've designed and written a solution from scratch, without even trying to contribute to the udev effort. (And while, I might add, another MV engineer contributed several patches to in his free time to help package and productize it.)
I fail to see your point in this project. AFAIC, you've wasted your time. It surely can't be customer requirements, as I highly doubt any customer solutions are based on a 2.6 kernel yet. You've completely duplicated the efforts of a project destined to become the de facto standard for the requirement you're trying to fulfill, for what gain?
Pat
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · Mark Bellon
The uSDE was built in response to a set of telco and embedded community requirements. We found it difficult to express our ideas. Everyone wanted to see code and documentation. Here is the code and the initial documentation. This is a starting point...
That makes perfect sense. If it helped to articulate and understand your ideas and concerns, this is certainly an important starting point.
Quoted 3 lines
Quoted 1 line
If not, are you planning on merging your efforts with udev in the future?
It is to everyone's advantage to converge on an implementation of enumeration that meets all of the requirements.
Great! However, I suggest that you should explore this idea yourself. Only you can eventually articulate the requirements and solutions in your code; you cannot expect others to go look at it and guess them.
Sincerely,
Lars Marowsky-Brée <[email protected]>
Signature · 15 lines
High Availability & Clustering \ ever tried. ever failed. no matter. SUSE Labs | try again. fail again. fail better. Research & Development, SUSE LINUX AG \ -- Samuel Beckett ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 14 lines · Greg KH
Quoted 11 lines · Mark Bellon
The uSDE was built in response to a set of telco and embedded community requirements. We found it difficult to express our ideas. Everyone wanted to see code and documentation. Here is the code and the initial documentation. This is a starting point...
Quoted 4 lines
If not, are you planning on merging your efforts with udev in the future?
Quoted 9 lines
Quoted 4 lines
It is to everyone's advantage to converge on an implementation of enumeration that meets all of the requirements.
What are your requirements, and why does udev not meet them? Is there some major disagreement between what udev does, and what you want to do? If so, what?
The requirements were collected from the OSDL CGL requirements specification version 1.0 and 1.1 ratified September 2002. They come from extensive discussions with the OSDL members as part of the definition of these requirements, expounding on them:
* The embracing of all device types with no specialization or limitation.
* The ability to have total control over the handling a device via external policy programs. Policy programs are invoked with a formal command line and description of the event that caused there invocation.
* The "service container" concept. A device is classified (or recognized by a pattern match) and this raises an (queued) event which is caught by a configurable "service container". The container is an ordered list of handlers that process the device.
* Event queuing and aggregation. Minimizing the number of program invocations (fork/exec) is critical in embedded environments - small processors.
* Aggressive device enumeration. Multiple concurrent policy execution and management.
* Device information persistence is a function of device policies, not the enumeration framework.
There are many situation where persistence is not an issue at all or only in specific cases (like disks). Why always pay for the memory/disk, for persistence, when it is not (always) necessary?
* Transactional protection of multiple configuration files is necessary. Multiple configuration files must often be modified in unison and insurance is necessary that an accurate and correct set of data is used when processing devices.
Quoted 6 lines
udev has been out in the world since April, any reason for not helping out with the existing project instead of going off and starting your own? It's not that I mind competing projects, it's just that I don't see your reasoning as to why there needs to be two different ones.
The two packages take philosophically different approaches and arrive with (largely) overlapping and some non-overlapping capabilities - after all they are both trying to do "the same thing". The uSDE has strengths and weaknesses just as udev or any program does. It is certainly possible to discuss changes (and make patches) to udev to incorporate the key issues addressed in the uSDE implementation.
The uSDE is an encapsulation of ideas and techniques. It is "complete" enough for those ideas to be discussed in a community setting and we can see how/what to move things together. Think of it as the projects "resting place" from which to confidently discuss techniques and implementions.
mark
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 42 lines · Patrick Mochel
Quoted 6 lines
The uSDE was built in response to a set of telco and embedded community requirements. We found it difficult to express our ideas. Everyone wanted to see code and documentation. Here is the code and the initial documentation. This is a starting point...
I find it difficult to see your justification for designing a project from scratch instead of contributing your time, effort, and ideas to a pair of already existing, albeit immature, projects that do exactly the same thing.
Please note that I'm not trying to incite yet another device naming flame war, but you have to understand how frustrating it is to see you guys make the same mistakes over and over, ad inifitum.
Let's review. SDET was posted several months ago by the Montavista telco group as a 2.4 solution that was driven by customer requirements. So be it.
In the last year, you (and/or your group) has posted several proposed device naming solutions; each of which were shot down because of over-design, misdirection, or simply tastelessness. Each time we encouraged you to align yourselves with the overall design goals or simply contribute to existing projects.
Personal contact in Ottawa resulted the same message. IIRC, many if not all, of the atttending MV telco engineers even saw Greg's talk on udev.
In the time since, you've designed and written a solution from scratch, without even trying to contribute to the udev effort. (And while, I might add, another MV engineer contributed several patches to in his free time to help package and productize it.)
I fail to see your point in this project. AFAIC, you've wasted your time. It surely can't be customer requirements, as I highly doubt any customer solutions are based on a 2.6 kernel yet. You've completely duplicated the efforts of a project destined to become the de facto standard for the requirement you're trying to fulfill, for what gain?
Quoted 5 lines
Pat
I can't respond to the emotion and ad hominum references in this message. The uSDE announcement is my first posting. I can't address any past dealings with MontaVista.
The uSDE ideas and implementation was started with the OSDL requirements in August of 2002.
This is the first time any form of it has been posted. From time-to-time, since the project started, ideas related to it have been floated with the community. The feedback was carefully listened to and utitized in the implementation that was just posted.
mark
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · Mark Bellon
Quoted 4 lines
What are your requirements, and why does udev not meet them? Is there some major disagreement between what udev does, and what you want to do? If so, what?
The requirements were collected from the OSDL CGL requirements specification version 1.0 and 1.1 ratified September 2002. They come from extensive discussions with the OSDL members as part of the definition of these requirements, expounding on them:
Wait, all the Carrier Grade Linux Requirement Definition Version 2.0 say about "Persistent Device Naming" is the following:
OSDL CGL specifies that carrier grade Linux shall provide functionality such that a device's identity shall be maintained when it is removed and reinstalled even if it is plugged into a different bus, slot, or adapter. "Device identity" is the name of the device presented to user space, and this identity is assigned based on policies set by the administrator, e.g., based on location or hardware identification information.
Which is all well and good, as nameif satisfies this requirement :)
But for you to read more into this, is fine, just don't say that it is required by the CGL spec.
Quoted 1 line
* The embracing of all device types with no specialization or limitation.
"all" is a wide range. Do you mean you are handling ethernet devices in uSDE? Why when nameif is already in use by all distros today, and satisfies almost everyone's needs.
udev does not handle network devices, because there is already infrastructure to handle them just fine.
Quoted 3 lines
* The ability to have total control over the handling a device via external policy programs. Policy programs are invoked with a formal command line and description of the event that caused there invocation.
Hm, like the "CALLOUT" function in udev?
Quoted 4 lines
* The "service container" concept. A device is classified (or recognized by a pattern match) and this raises an (queued) event which is caught by a configurable "service container". The container is an ordered list of handlers that process the device.
Ah, I love "design patterns" as much as the software engineer. But can you try to explain how this will help out any user? It just seems to make the code more complex and larger than it needs to be.
Quoted 3 lines
* Event queuing and aggregation. Minimizing the number of program invocations (fork/exec) is critical in embedded environments - small processors.
Wait, you say above that you have to be able to call out to "external policy programs". Now you say that you never want to call fork/exec, ever. Which is it?
And you all _keep_ saying this without ever providing any numbers to back this up. Linux has the fastest fork/exec than any other OS out there right now. Again, do you have REAL NUMBERS that show this is a problem? As I've found out in testing udev, devices are slow compared to fork/exec. My old, slow, and no memory 300Mhz laptop can _easily_ outrun the ability for the scsi core to create virtual devices. So much that I have to put sleep() calls in udev just to slow it down to wait for the kernel to catch up. Using real scsi devices is a piece of cake, they take seconds to initialize.
I think you have found the same thing in your testing, or so you nodded in agreement when I said this at the last CGL meeting.
Quoted 2 lines
* Aggressive device enumeration. Multiple concurrent policy execution and management.
"Aggressive"? That's an odd use of an adjective :) What does this really mean, in simple terms.
Quoted 2 lines
* Device information persistence is a function of device policies, not the enumeration framework.
What does this mean?
Quoted 3 lines
There are many situation where persistence is not an issue at all or only in specific cases (like disks). Why always pay for the memory/disk, for persistence, when it is not (always) necessary?
What memory? udev is only 45Kb, static, which I know is _quite_ different from uSDE, based on the number of shared libraries you use, and build :)
Anyway, if you don't have a rule for a device, udev just uses the kernel name, no harm or overhead there. What is the real point here?
Quoted 4 lines
* Transactional protection of multiple configuration files is necessary. Multiple configuration files must often be modified in unison and insurance is necessary that an accurate and correct set of data is used when processing devices.
Ah, mom and apple pie. I love those things too. But what is the real point? Don't have multiple config files? If that's a real problem, then don't do that. Or put your config into a database if again, it's a real problem. But I don't see the problem. An admin changes the config file, sends a SIGHUP to the daemon, which reloads the config file, and everyone is happy.
Why should this be any different from what runs important programs today, like your mail or web server?
Quoted 6 lines
Quoted 6 lines
udev has been out in the world since April, any reason for not helping out with the existing project instead of going off and starting your own? It's not that I mind competing projects, it's just that I don't see your reasoning as to why there needs to be two different ones.
Quoted 6 lines
The two packages take philosophically different approaches and arrive with (largely) overlapping and some non-overlapping capabilities - after all they are both trying to do "the same thing". The uSDE has strengths and weaknesses just as udev or any program does. It is certainly possible to discuss changes (and make patches) to udev to incorporate the key issues addressed in the uSDE implementation.
Besides the refusal to handle network devices, I don't see any thing that udev is lacking that uSDE has. But I'm not too familar with uSDE, being that it has only been released for a few days now. If you could point out anything that udev is lacking, I would be glad to help solve that.
thanks,
greg k-h
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · Mark Bellon
The uSDE ideas and implementation was started with the OSDL requirements in August of 2002.
This is the first time any form of it has been posted. From time-to-time, since the project started, ideas related to it have been floated with the community. The feedback was carefully listened to and utitized in the implementation that was just posted.
When floating those ideas, was it clear that an implementation was being actively developed? You could have said something when Greg posted version 0.1 of udev back in April.
If people had known that this was in the works, they might have chosen to concentrate on this rather than udev. As it is, there has been significant effort put into udev, and now there is duplicated functionality and more work will be required to figure out how to combine them (if that is the chosen path).
Chris
Signature · 16 lines
Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: [email protected] ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · Mark Bellon
I can't respond to the emotion and ad hominum references in this message. The uSDE announcement is my first posting. I can't address any past dealings with MontaVista.
It might be your first public posting. But it is not your first email to people here ever. I have a few emails from you lying around here from back in Feb and March of this year in which you detailed this project. And you have been aware of udev from at least April, as it's code has been public since then.
I also have email messages from Intel employees who were helping you with uSDE over the past few months, asking questions about different things that udev does, in order to get a better understanding of it. I'm guessing that was done to provide that functionality in uSDE, which is fine.
The major frustration of mine is why, if you found udev lacking for one reason or another, did you decide to not help us out, and instead go off and work on your own, in secret? We could really use the help with udev, and having at least 2 full time people working on it (like it looks like uSDE has) would make a real difference.
Quoted 3 lines
The uSDE ideas and implementation was started with the OSDL requirements in August of 2002.
This is the first time any form of it has been posted.
Again, in public. I have older code drops of yours in my email folders.
Quoted 3 lines
From time-to-time, since the project started, ideas related to it have been floated with the community. The feedback was carefully listened to and utitized in the implementation that was just posted.
I have provided help to you and your team over time, but that has been a one-way street. Help has not flowed back the other way, even when we have asked for it (help with udev, or with the kernel changes that are required for udev or uSDE to work properly.) That is why I am frustrated, and I think that others in the open source community have the same frustration.
udev isn't going away any time soon, and I am committed to working on it for quite some time in order to address issues people have raised. If you want to spend your time on uSDE, that's up to you. I'm very willing to work with your team, if your team is willing to work with us.
thanks,
greg k-h
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines
Quoted 5 lines
The requirements were collected from the OSDL CGL requirements specification version 1.0 and 1.1 ratified September 2002. They come from extensive discussions with the OSDL members as part of the definition of these requirements, expounding on them:
Wait, all the Carrier Grade Linux Requirement Definition Version 2.0 say about "Persistent Device Naming" is the following:
Quoted 7 lines
OSDL CGL specifies that carrier grade Linux shall provide functionality such that a device's identity shall be maintained when it is removed and reinstalled even if it is plugged into a different bus, slot, or adapter. "Device identity" is the name of the device presented to user space, and this identity is assigned based on policies set by the administrator, e.g., based on location or hardware identification information.
Thanks for point out the actual CGL requirement, Greg.
Quoted 7 lines
Quoted 6 lines
The two packages take philosophically different approaches and arrive with (largely) overlapping and some non-overlapping capabilities - after all they are both trying to do "the same thing". The uSDE has strengths and weaknesses just as udev or any program does. It is certainly possible to discuss changes (and make patches) to udev to incorporate the key issues addressed in the uSDE implementation.
Quoted 6 lines
Besides the refusal to handle network devices, I don't see any thing that udev is lacking that uSDE has. But I'm not too familar with uSDE, being that it has only been released for a few days now. If you could point out anything that udev is lacking, I would be glad to help solve that.
The Carrier Grade Linux specification has never dictated an implementation. In fact, both udev and uSDE are listed as potential implementations.
As Lars stated in an earlier email, "Competition is good, but only if they explore distinct approaches". It is a shame that much effort has been duplicated here on similar approaches. I'm not fully aware of the history behind the divergence, but it makes sense to enumerate NOW what is lacking in udev from a uSDE perspective. One objective of the carrier grade initiative is to prevent duplicate effort. Now that we have two implementations, let's get the issues/differences on the table and cooperatively move to convergence.
John
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · John Cherry
As Lars stated in an earlier email, "Competition is good, but only if they explore distinct approaches". It is a shame that much effort has been duplicated here on similar approaches. I'm not fully aware of the history behind the divergence, but it makes sense to enumerate NOW what is lacking in udev from a uSDE perspective.
I'm not aware of why there was a divergence in the first place either :)
As udev has been public for a long time now, would someone from Monta Vista care to detail why they found udev lacking and deserving of a duplicate effort?
Quoted 3 lines
One objective of the carrier grade initiative is to prevent duplicate effort. Now that we have two implementations, let's get the issues/differences on the table and cooperatively move to convergence.
I'm trying :)
greg k-h
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel