From: David McCullough (davidm@snapgear.com)
Date: Wed Sep 18 2002 - 11:08:25 EDT
Jivin Jay Vaughan lays it down ... ... > I'm sorry if I came across as unappreciative - in fact, I *do* > appreciate how much hard work has gone into the uClinux-dist package, No problems, > which is why I'm so frustrated at times that I can't use it properly > because of not knowing *how*. > > There's little point in having done all that work in the first place, > if it's not accessible to newcomers. This is a point that needs to > be addressed, and in an effort to support the work already done by > giants before me, I would like to assist in the effort to make this > easier to use as much as possible. It's feasible that I'll be using > ucLinux a lot - if that's the case, I'll be involved in this > community as much as possible, and will help out where I can. I am sure I have seen some of your issues flow by on the list, but I can't remember them. If you could list the major issues that caused you trouble and prevented you getting it to go we could look at why they happen and perhaps even find a way to prevent it happening again. > >It's a little hard to tar and feather the uclinux build process. It is the > >same as that for linux (uclinux is just the kernel after all :-) > > Ummm... linux doesn't have userland, and it doesn't have libs like > ucLibc, so I think this is just a little too smooth a reply. The > fact is, the ucLinux build process *has* been tarred and feathered - > by all the different libs and target environment settings that were > added to the top of the regular linux kernel build process... But if you wanted to build a linux system you would need libs and apps. I also think a lot of people would find their first raw linux config fairly daunting. We often see people on the list with problems because they have turned on a kernel option they don't understand. Nothing against people who encounter this, it required a certain amount of linux knowledge to be comfortable with it. > >The uClinux-dist however manages multiple apps, kernels, libraries and > >target platforms in the one source tree. Look at the combinations, it's > >a non-trivial task to make something this big fault free. Without something > > Right, which means its time to re-engineer the design of this tree. > It's getting too big, and too unmanageable for people who were not > here from the beginning ... I don't believe so at all. What we had before the uClinux-dist was bits and pieces of stuff all over the place. I can assure you that I am much more productive with everything tied together is an environment like uClinux-dist. I switch platforms regularly and use libs/apps as needed on each one. Simiarly for kernels. The good thing about the dist is that if you want to use it, but don't need one of the kernels or libs you can remove it and the option disappears making your own source tree much simpler. I think the choices in the uClinux-dist are ones of it's strengths. Embedded systems have many and varied requirements. Take away the choices that are there and the tree may not be useful for the next persons particular embedded target. Of course lots of choices makes it harder to get started, but I have been in the situation where my choices are limited and it's just as frustrating :-) At the top level in the uClinux-dist the choices are fairly simple, platform, kernel, libc. We could possibly make it even simpler by having each target default the kernel and libc portions to it's preferred ones. > >If it targetted one platform, say the mcf5272, then it would be easy to > >remove all the combinations that don't work. Trouble is it doesn't and what > >is used on one platform may never be used on another. Thus you see people > >asking why doesn't this compile type questions. > > Right. And *this* is extremely frustrating and counter productive. > I don't care what the justification is for why it is that way now, I > only want to fix it so that it gets *better*, and ucLinux gets > *better* for people to use as a product. > > If there is a fix that requires strenuous engineering effort on a > regular basis (keeping updates in sync), compared to a fix that > requires a bit of engineering effort on a larger scale, one-time-only > basis, I think I'll choose the latter... I fail to see how any way of splitting all the parts of the uClinus-dist up can result in less work. Either all the useful combinations are represented somewhere or they no longer exist. The number of apps, libs and kernels will not changejust because they are split up. Perhaps I am missing the obvious. > >What would be useful is for people to maintain portions of it that we do > >not care about and actually send in patches to make it work. If you try > >something, it breaks, and you fix it, send in the changes ! > > Yes, so that 1,000 other people then can have the headache of having > to work out how to patch their local source tree properly to > implement my fixes, some of which may or may not be appropriate to > them, accordingly. > > I hate to say this, but maybe its time to fork the different > architectures into smaller units, separate userland build processes > (including libs) from kernel build processes, and try to make things > a little more open from the beginning instead of piling it all into > the one -dist package ... IMO this is going backwards to what we had previously, and that wasn't working. > >At the end of the day you are trying to get a development environment > >for your business. Stability is something you will no doubt want. To > >truly achieve this you just cannot take anything off the net without > >looking at what is changed and whether or not it is suitable for your > >application. For example, uClinux-2.4 just moved up to 2.4.19, but for a > >stable product I would not immediately move to 2.4.19. As you said you > >are mainly interested in apps, it doesn't matter what kernel you use > >unless you need new features or bug fixes that you cannot get any other way. > >There is no short cut for source management, you have to manage it to suit > >your particular needs. CVS can help, but it isn't the complete solution. > > I agree with your sentiment here, but I think that the management of > the -dist package needs to be reviewed a bit more subjectively by > those that maintain it, from the perspective of new/potentially new > ucLinux users. > > It is a nightmare for a newcomer, I'm sorry. Get us a descriptive list of the things that stopped you from getting going easily and we can work on ideas to make this process easier. The best way for us to make it better for newcomers is to find out why it is not working for in it's present form. > I'm offering to help, but from my weak position trying to play > catchup, I don't know how much I can do other than be the rabble > rouser that gets you old timers thinking about these sorts of things, > hopefully without too much stigma. Someone has to rock the boat :-) Cheers, Davidm -- David McCullough: Ph: +61 7 3435 2815 http://www.SnapGear.com davidm@snapgear.com Fx: +61 7 3891 3630 Custom Embedded Solutions + Security This message resent by the uclinux-dev@uclinux.org list server http://www.uClinux.org/
This archive was generated by hypermail 2.1.4 : Thu Sep 19 2002 - 13:21:54 EDT