Hi Brian,

You shared good thoughts, thanks. The current status is, folks from USB, 
HAL and JDS teams are working together on the project. Experts from 
userland to kernel are included. Sure, more people from different teams 
will be involved. We also had quite a few discussion with Vijay who 
proposed the similar project about two months ago in order to work 
together to move the project forward. As regards our proposed different 
technical solution, we will have a deep discussion in the following. It 
is a good thing to see different ideas and I believe the ideas will make 
the project better.

It is an opensource project and will be developed in community. The more 
people involved, the better. We are in the beginning stage now. The 
first step is just to kick off the project and have a project page for 
people to share ideas. In the following, we will collect the necessary 
feedback and then have the detailed design according to the exact 
requirement. Let's start it and enjoy.

Thanks,
Strony

Brian Cameron :
> Strony:
>
>   
>> At fact, we are the USB device driver team. We are working on both USB 
>> and HAL fields now. Last year, Simon (JDS team member) and I worked out 
>> a simple prototype based on Gnome-device-manager by which users can 
>> enable/disable the USB devices. The screenshot about the GUI demo is 
>> attached. If necessary, we will contact with other kernel teams to move 
>> the project forward.
>>     
>
> It sounds like we recently discovered that there is a separate project
> working on similar technology.  It would be a good idea to touch base
> with them, and talk through these issues to make sure we are on the
> same page.
>
> Ideally we should have some answers to the following sorts of questions:
>
> - Do the two projects overlap or do they provide unique functionality?
>    In what areas do they provide unique functionality?  Are there
>    opportunities for the two projects to further converge?
>
> - What kernel groups does the other Device Management project have
>    a relationship with?  Is it the same groups as the ones you are
>    working with?  If not, does this mean your group should develop
>    a closer relationship with these other kernel groups?
>
> - It would be handy to have a better understanding of the pros and
>    cons of the two applications and to have a more clear story about
>    why having both adds value.
>
> You say above that you will only contact the other kernel groups if
> necessary to move the project forward.  How do you know if it is
> necessary without first contacting them?  I would think we would
> need to learn about the requirements of the other Device Management
> project to understand how this project fits in.  To do this, isn't
> it necessary to develop a dialog with them?
>
> There have been some situations within Sun where projects have
> gotten canceled because there was a competing project that did the
> same thing.  You reduce the risk that your project will eventually
> get canceled if you make sure that you start dialogs early when
> you discover there are potentially competing projects being worked
> on by other teams within Sun.
>
> Brian
>
>
>   
>> simon.zheng at sun.com :
>>     
>>> On Thu, 2008-03-27 at 11:22 -0500, Brian Cameron wrote:
>>>  
>>>       
>>>> Irene:
>>>>
>>>> Obviously a project which is intended to manage devices needs to
>>>> interact with the kernel, where the devices actually live.  Although
>>>> the reasons you give below are good, you don't give any indication
>>>> that there has been any dialog with the appropriate kernel teams to
>>>> make sure this project is in-line with their plans, that they intend
>>>> to support the needed HAL interfaces, etc.
>>>>
>>>>    
>>>>         
>>>>> Opensolaris is an open community, there's no policy that projects with
>>>>> similar functionality should not co-exist in the community.
>>>>> I am not familiar about the other device manager project. I was told
>>>>> that both the structure and the GUI are different. If this is the case
>>>>> I'd say that it won't hurt to have both these projects on 
>>>>> opensolaris.       
>>>>>           
>>>> Has there been any dialog with the appropriate kernel groups to
>>>> ensure that this project will be an ongoing success?  There has been
>>>> mention of an existing Device Manager project.  Does this other project
>>>> already have the buy-in of the kernel groups?  What is their opinion
>>>> of having multiple projects with similar functionality?  Are they
>>>> willing to support needed interfaces interfaces for both Device Manager
>>>> projects?  What are the issues, if any, in this space?
>>>>     
>>>>         
>>> As I known, Strony's proposal is based on X86 driver development team
>>> requirement, especially hotplug devices really desire it.
>>> Enable/disable hotplug device is very useful I think. So I'm sure USB
>>> guys would like to support. Currently HAL + gnome-volume-manager can
>>> already automatically mount USB storage device. But it doesn't seem to
>>> deal with other kinds of USB devices.
>>>
>>> For non-hotplug devices, perhaps we need more feedback.
>>>
>>> With regard to gnome-device-manager, it has a bit of history. Before HAL
>>> v0.5.9, a subordinate GUI tool "hal-device-manager" written in Python is
>>> widely distributed on Linux and FreeBSD. In the latest HAL 0.5.10,
>>> hal-device-manager is rewritten in C and deliever a separte project
>>> called gnome-device-manager.
>>>
>>> Anyway, personally I like such a gnome-device-manager to deal with
>>> hotplug devices, e.g. allowing me to manually unable/disable usb device
>>> from system tray, or notification can be popep up in system tray when I
>>> plug USB device.
>>>
>>> -Simon
>>>
>>> _______________________________________________
>>> desktop-discuss mailing list
>>> desktop-discuss at opensolaris.org
>>>   
>>>       
>> ------------------------------------------------------------------------
>>
>> This body part will be downloaded on demand.
>>     
>
> _______________________________________________
> desktop-discuss mailing list
> desktop-discuss at opensolaris.org
>   


Reply via email to