On 29.05.19 10:04, walter harms wrote: Hi,
>> basic rule: don't use vendor kernels for production, unless you >> *really* *really* have to. > > we have custom hardware, so this was needed. Custom hardware doesn't necessarily need a vendor kernel. Most cases should be happy w/ board specific DTS, possibly some extra drivers, sometimes perhaps a few extra tuning patches. But: such development, IMHO, should always happen on recent mainline and things that aren't really customer specific should be upstreamed as early as possible. Vendor kernels are a different thing: usually they pick some older base versions, do lots of strange things to get their hw somehow working, and - one of the worst things one could do - merge down things from mainline into their fork. After a few iterations, the code gets pretty much unmaintainable. Such things are probably nice for a sales demo, perhaps emc tests, but certainly not for production. Just have a look at typical android vendor kernels. Horrible. >> HW vendors usually don't have the capacities to offer any decent >> kernel support. there're only few exceptions (eg. phytec) that have >> their own kernel hackers and actively participate in upstreaming. > > We have noticed that also, *active* is a big point. Yes, but most hw vendors even never have been active in the first place. Even if a particular company is doing that in *some* area, it doesn't necessarily mean they're doing it for your particular product. Just look at Intel, and what mess the produced for their flopped sofia soc. >> by the way: should we create a separate list for commercial topics ? >> > > I used linux-arm and it worked surprisingly well (not all mails went truh the > list) > but it look very silent and i was unsure if they were still alive. IIRC, linux-arm is for arm specific development. Sure, the chance of finding some consultant there is better there, as arm just has a huge market share in embedded world. > A big win > for everyone would be a FAQ/Lessons-learned something you can take to check a > contract. > the customer will know what to expect and the contractor will know what to > offer. hmm, if anybody else here is interested in that, let's start with that. maybe these discussions might be better off-list ? > Having something a list of minimum requirements like that FAQ would improve > the stand of > the hardware developed to support linux. Not everyone has a big budget or > need to > produce in millions like the raspi guys did, and even they have sometimes > troubles. Well, one of the basic rules, IMHO, would be: if you're going to do some linux embedded project, you should do a proper evaluation: * check whether the board is already supported by mainline kernel (try to get a running mainline kernel built by yourself) * never use vendor kernels at all * check whether your supplier has active kernel hackers and actually does mainline integration * if you run into any problems here, call in a linux embedded and kernel export - *soon* in the project You spend a few extra bucks for the consultant, but he'll protect you from the wrong choices, eg. buying unsupported / badly supported hardware. In recent years, I had many clients that called me in far too late. One eg. was trying to build a medical device, using custom boards (very high hw development costs and long timeline, due to qualifactions, etc), with fancy HMI, but picked imx53, where no *usable* gpu driver exists. When I brought the bad news, the project already ran for several years and nobody dared to restart board development. (in the meantime, long after i've gone, they indeed create a new board w/ mx6). Such things could easily prevented if people just wouldn't trust the hw vendor at all and ask us (kernel hackers) early. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
