my comments below inline. -Igor
> On Dec 20, 2018, at 12:56 AM, Joshua M. Clulow <[email protected]> wrote: > > On Wed, 19 Dec 2018 at 10:04, Igor Kozhukhov <[email protected]> wrote: >> We are, Argo Technologie SA, are using DilOS platform for business needs. >> >> it was very hard to contribute changes related for DilOS needs because I was >> asking to use illumos based tools like: echo, ed, etc - they are no >> compatible with GNU coreutils, GNU find, GNU grep, GNU sed, etc... >> but i have provided solutions to be a more universal, where we can use >> another tools. > > I think people have tried to address this with you a lot over the > years, but I'll try again. It's been a while, but as I recall the > problems arose with changes you wanted to integrate that you were not > willing to test. I recall personally trying to help you understand > how to test the changes, and obviously if you want to integrate > changes in the future I imagine we'll try to help again! well, put back again with examples. illumos build depend on illumos version of tools like: 'echo', 'ed', ’nawk', etc if you want try to build illumos-gate as is, you need these tools to be available on build host. on DilOS we have no several illumos based tools for builds and, as result, build failed. I tried to reproduce original illumos-gate build on dilos, but it is impossible without changes in illumos-gate sources for it, because original dilos build host has another versions of tools and they are incompatible. >> 1. Can illumos accept changes for distribution with #ifdef <DISTRIBUTION> >> #endif ? >> because with DilOS we prefer to use another logic in zones and BE. >> example of some changes with #ifdef: >> https://bitbucket.org/dilos/dilos-illumos/commits/1f0c193cc1a31345fd0f3875fe496bbb963e2261 > > I don't understand what this change does, but I suspect it would be > better to rephrase it as some kind of configuration or feature keyed > off of a particular zone brand. In general, I think we'd like to > avoid #ifdef code like this because it's effectively dead code in the > gate (most people will not be building it most of the time) and we > have enough of that to clean up already. additional info: with smartos, you are not using beadm on host with zones for upgrade. omnios and OI are using IPS and needs to do some mounts to new BE for their scenarios. on DilOS we are using APT/DPKG and do not want to do anything with zones when we upgrade global zone or create new BE. example: i want to test new modules. i can do: beadm create newBE beadm mount newBE /a apt -R /a install driver-adc bootadm update-archive -R /a beadm activate newBE reboot with these steps i do not need mount zones root - i want to play with global zone and i know: no impact zones in these scenarios. also, we have separate tool - os-upgrade - where we identify additional steps if needed fo updates/upgrades/etc my proposal for #ifdef DILOS - just for tools, where we can do change of logic of some tools, what are provided by illumos-gate, but with distribution specific cases. >> 2. Can illumos accept to use another bulid tools for distribution needs with >> distribution target? >> example: identify distribution variable in Makefiles and use it only for >> special distribution. > > I'm not sure I understand the question. Do you mean making particular > parts of the build optional? If so, I believe we've already made some > changes like this recently with respect to the Python modules that > currently reside in the gate. example for this in first place where was described issue for illumos based tools to be available for illumos builds on build host. another big issue: we have no ability on build system for disable components and use is per distribution. example: on DilOS we are using APT/DPKG and no need IPS, svr4 pkg also, several tools/components was replaced by userland builds: - libtecla - use from userland - illumos make - moved to userland - libsqlite2 - moved to userland - policykit - moved to userlnd - curses -> replaced by ncurses - etc and we are not using java dependencies and python dependencies for dilos-illumos builds - some tools/components was removed, some was replaced by userland apps we no need to build svr4 pkg and others tools for reduce of build time. one proposal for shared sources: to use distribution specific targets for enable/disable some components on bulid env. how to do it with current list of components on surrent illumos-gate tree ? additional example: on Debian build tools/env we have vendoring files and they are providing special variables based on build host: it is Ubuntu, Debian or something else. it is easy in this case to have ability for manage Makefile in some targets/special flags for builds on different build hosts. >> 3. we are, Argo Technologie SA, wants to working on support of Russian >> SPARC based platforms. >> right now - R1000 = sun4u. >> http://www.elbrus.ru/arhitektura_sparc >> (yes, it is text on Russian, but info about SPARC R1000 can be found in >> English) >> >> new one - https://ru.wikipedia.org/wiki/МЦСТ-R2000 >> >> will illumos advocates are interested in updates? > > This is a big enough subject that it'd be worth having a whole > separate discussion. I don't know anything about Russian-made SPARC > systems, so it's hard for me to know how realistic they are as a > target for illumos. Some questions include: who's actually going to > maintain the hard parts, like support for new compilers and drivers > for new pieces of hardware? How expensive are these systems to buy, > and are they being produced in a large enough quantity that they will > be easy to obtain? As we begin to provide more centralised build and > test infrastructure, we'll want to consider what it would mean to > include SPARC in the matrix. > > This mailing list thread is probably not a good venue for this > discussion. I'd recommend taking a look at the documents we've > written so far in the IPD repository, and considering putting together > a document that describes your vision for these other SPARC machines: > > https://github.com/illumos/ipd about SPARC. i have no answers on all questions yet, because we are on the way in duscussion about feature sets and hw specific. R1000 sun4u was similar to older sun fire v210/v240, but with some additional specifications in HW list. abotu R2000 we still have no full spec with compatibility list yet. >> the same question about Xen - if advocates cant check it - how to contribute >> it ? > > I think at this point the Xen paravirt support we have is truly > ancient. The mess of i86xpv #ifdefs in the kernel get in the way of > new development. It seems much more likely that we would remove a lot > of what we have today, and instead provide drivers (in the style of > vioif/vioblk) for whatever emulated hardware Xen exposes in their > newer fully virtualised model. in this point , you drop technology what is using by another distribution and can’t put back if Xen will be in busness in some days? it’s a very pity, because others questions about shared codes base for distributions - are not possible. if one distribution use SPARC/Xen, but Joyent not - it is question again: what is it illumos-gate? Joyent has smartos, and it is not the same with illumos-gate tree. why you want remove another technologies/sources from illumos-gate if they can be used by others distributions? I respect Joyent and everything you do. But it is very pity to see your possition about SPARC and Xen - it is my persinal comment/position. >> What about distribution specific changes in illumos tree ? is it possible ? >> >> right now only one way is possible - support of personal fork. > > The answer to this question always depends on what the change is. We > can't really answer a question like this without looking at the > change, understanding the impact for other distributions, on long term > maintenance, etc. This mailing list thread is also probably not the > place to discuss this -- if you have specific proposals to consider, > we should discuss them separately. all my comments are development specific and can be interested in for others who are on this list and have similar/same visions/issues. > > Cheers. > > -- > Joshua M. Clulow > Engineer @ Joyent > http://blog.sysmgr.org > > ------------------------------------------ > illumos: illumos-developer > Permalink: > https://illumos.topicbox.com/groups/developer/Td3185838722eb01a-M72d10801cd1929f524cadc85 > Delivery options: https://illumos.topicbox.com/groups/developer/subscription ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T03dff29b8e1125f4-Mdde5c97e8b83c55b5b2b5617 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
