Hi Alan, Am 24.01.2016 um 18:10 schrieb One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx>: >>> but by having only the >>> minimum necessary in the kernel. Unix >> >> I think you are confusing it with the goals of microkernels (e.g. Mach or Hurd). > > No and the quote below is from Doug McIlroy - who amongst other thing > invented pipes. Which is a brilliant concept. > >>> >>> "We used to sit around in the Unix Room saying, 'What can we throw out? >>> Why is there this option?" - Doug McIlroy Maybe I am interpreting differently, but "throwing out unnecessary things from Unix" is logically not the same as "having the minimum necessary in the kernel". The latter appears to be implying to do *everything* which can be done in user space. This is what I mean that the goal of throwing out everything not necessary from the kernel leads to micro-kernel concepts. And neither Unix nor Linux did throw out enough to become a microkernel. So they still have components which could be thrown out and moved to user space. And Unix is kernel + user space. So the citation could also mean that they did throw out (and simplify) concepts in both areas. Not only from the kernel. So they did balance and optimize the whole system (which is what I want to achieve as well). Unfortunately I never had a chance to meet one of the Unix inventors, so I can't ask them what they really meant and how they did work. But anyways, this is discussing the wrong problem on the wrong level. People out there (and me included) would like to hide or better, easier and more systematically access devices directly connected on the same PCB to a specific UART. And can't. Or can do only with ugly or inefficient solutions. >From that we come to this fundamental discussion level because you say that Linux should be a kernel which should only support the minimum. Therefore our requests are rejected, because it could be solved by blowing up the user space. This is IMHO your very valid opinion, but it is not a guideline that I observe when going through the source tree. There are tons of things that could be done in user space (e.g. what are all those I2C device drivers good for? /dev/i2c should suffice to control every device from user space. What is iio good for in the kernel? a library could translate everything into iio interfaces). So this discrepancy is what I criticize because I don't see a basic rule or design principle behind what is acceptable and what is not. If it exists, please point me to it. I am open to learn about that. > >> Most GPS receivers I came across are modules which spit out NMEA >> records with serial 9600 bit/s. Either through RS232 or Bluetooth SPP. There >> may be others, but I don't want to have all problems of the world solved >> at once. > > The kernel lives in the big world, not your personal fiefdom Every contribution initially looks at the area, the contributor is aware of and knows best and does not find a solution using existing hooks. Then discussion starts. But what a contributor can't (and should never) accept is if his problem is simply declared to be a non-problem without providing a *better* alternative solution for it. Better for everybody including the contributor. > > *PLONK* Thanks. Well, I have to apologize that I was not yet aware who hides behind the "one thousand gnomes" e-mail address... Because I judge discussion partners by what they say now and how they help to solve my actual problem for the future (and not what they have done in the past). So you do have a lot of experience with Linux history. And you are amongst the handful of persons who know every detail of the Linux kernel. That is good because it shows that you can really influence how this discussion ends. But sometimes experience could be a little blocking to new ideas and experiences not related to Linux (e.g. close to hardware or embedded design) brought in by newcomers. And it collides with my belief that everything can be done, if people want. Now, how can we help those who want (for IMHO very understandable reasons) to access a specific UART from kernel modules? -- hns -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
