Richard Weinberger wrote: >> Auto-detection of SUBARCH, which can be done with a simple call to >> uname -m (the 90% case). The second patch I submitted prevented >> spawning xterms unnecessarily, which we discussed was a good move. > > Covering only 90% of all cases is not enough. > We must not break existing setups. > That's also why my "Get rid of SUBARCH" series is not upstream.
Mine covers 100% of the cases. My series is about auto-detection of SUBARCH, not its removal: you can still set a SUBARCH from the command-line; existing setups don't break. > Your second patch changed CONFIG_CON_CHAN to pts, which is ok but not > a major issue. "Major" or "minor" is purely your classification: don't impose your value judgement on reasonable patches. I am the user, and I demand a pleasant build process and ui. Moreover, how do you expect more contributions to come in until existing patches make it to upstream? > The xterms are also not spawning unnecessarily they spawn upon a tty device > is opened. > With your patch UML create another pts. Thus, the spawning is hidden... It connects to an existing host pts device instead of spawning a new xterm and connecting to the console io on that. Why is that not desirable? > I did not push it upstream because it depended on your first one and as I > said, it's not critical. > This does not mean that I moved it to /dev/null. ... and you still haven't told me what's wrong with my first patch. > Again, the plan is to get rid of SUBARCH at all. You've been harping about this plan for the last N months, and nothing has happened so far. It's time to stop planning, and accept good work. >>> make defconfig ARCH=um SUBARCH=x86 (or SUBARCH=i386) will create a >>> defconfig for 32bit. >>> make defconfig ARCH=um SUBARCH=x86_64 one for 64bit. >> >> Yes, that's how I prepared the patch in the first place. > > So, nothing is broken. So the user is Ugly and Stupid for expecting: $ make defconfig ARCH=um $ make -j 8 ARCH=um to work? Stop denying problems, no matter how "major" or "minor" they are. > If you want "make defconfig ARCH=um" creating a defconfig for the correct > arch you need > more than your first patch. No, you don't. Try it for yourself and see. Set a SUBARCH if you like, and it'll still work fine. > Again, "Get rid of SUBARCH" series has the same goal. For the last time, getting rid of SUBARCH is Wrong and Undesirable. -- 8< -- Here's a transcript spoonfeeding you the impact of my first patch: $ make defconfig ARCH=um SUBARCH=i386 *** Default configuration is based on 'i386_defconfig' # # configuration written to .config # $ make defconfig ARCH=um SUBARCH=x86_64 *** Default configuration is based on 'x86_64_defconfig' # # configuration written to .config # $ make defconfig ARCH=um *** Default configuration is based on 'x86_64_defconfig' # # configuration written to .config # In the last case, notice how defconfig automatically picks up x86_64_defconfig correctly: if I were on an i386 machine, it would have picked up i386_defconfig like in the first case. Without my patch, the last case would have incorrectly picked up an i386 defconfig, which is Stupid and Wrong. ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
