Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

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