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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <68E21655-A8A1-431B-BBB9-3B43AFC0B03A@goldelico.com>
Date:	Sat, 23 Jan 2016 23:04:09 +0100
From:	"H. Nikolaus Schaller" <hns@...delico.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Tomeu Vizoso <tomeu@...euvizoso.net>,
	Rob Herring <robh@...nel.org>,
	Vostrikov Andrey <andrey.vostrikov@...entembedded.com>,
	Mark Rutland <mark.rutland@....com>,
	Peter Hurley <peter@...leysoftware.com>,
	Rob Herring <robherring2@...il.com>,
	List for communicating with real GTA04 owners 
	<gta04-owner@...delico.com>, NeilBrown <neil@...wn.name>,
	Arnd Bergmann <arnd@...db.de>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sebastian Reichel <sre@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
	Grant Likely <grant.likely@...aro.org>,
	Jiri Slaby <jslaby@...e.cz>,
	Marek Belisko <marek@...delico.com>
Subject: Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4


Am 23.01.2016 um 18:28 schrieb One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>:

>>> There is lots of stuff we probe and bind via user space - most things
>>> these days in fact. That's much of why we have notifiers and udev. It's
>>> frequently a win in flexibility, security and configurability to do stuff
>>> via user daemons. We do it for example with all the volume management,
>>> raid and disk encryption.  
>> 
>> Because volumes are something users really want to configure. They
>> can change their hardware configuration every now and then. And
>> there are removable media to be considered.
> 
> Like USB bluetooth dongles, like systems with external SPI ports, or plug
> in SPI devices, or plug in gps devices on other interfaces ?
> 
>> In our UART cases the underlaying hardware can't be reconfigured. So
>> there is no need to load this burden of config to the user.
> 
> Plenty of uarts it can be or the BT can be muxed with other device
> endpoints.

Please give examples where the user can configure such a chip that is
soldered on the same PCB as the SoC.

> 
>> For BT or GPS I just want it to work the same on all devices (independently
>> on how the specific chip is connected). Kernel should unify such things.
>> Or it would not be a Un(iplexed)ix.
> 
> I think you are confusing Unix and Multics.

No, If I write Unix I mean Unix. The "Un" stands for "Uniplexed" which is
a pun of course. But it alludes to "Unification" giving the impression of
"Simplification".

> 
> Unix is nothing to do with Linux and Unix was about creating a beautiful
> system not by having a huge crap filled kernel,

and no crap filled user space.

> 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).

> was not about what was put in but
> what was left out.

Exactly. It left out complexity. E.g. everything is a file. You can use devices
like files. Just open some /dev/tty and get GPS NMEA records...

> 
> "We used to sit around in the Unix Room saying, 'What can we throw out?
> Why is there this option?" - Doug McIlroy

Fine. Let's throw out the idea to configure power on/off a GPS or BT device
by user space daemons for hard wired chips.

> 
> GPS is a train wreck for commonality. Most GPS requires custom binary
> only user space code often obfuscated in order to meet the regulations
> governing GPS technology to stop third parties using it for missile
> guidance.

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.

-- hns