linux-kernel - Re: [PATCH 0/4] drivers/misc: add rawio framework and drivers

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20131022054406.GA14163@kroah.com>
Date:	Tue, 22 Oct 2013 06:44:06 +0100
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Bin Gao <bin.gao@...ux.intel.com>
Cc:	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] drivers/misc: add rawio framework and drivers

On Mon, Oct 21, 2013 at 05:03:17PM -0700, Bin Gao wrote:
> To read/write registers from a device is very important on embedded system,
> especially SoC systems. Physically there could be different types of devices
> based on bus tyes, e.g. PCI devices, I2C (slave)devices, I/O devices(memory
> mapped), inter-processor devices, etc. Typically there are userland
> tools from
> PC Linux to access device registers, but on some embedded system initrd and
> rootfs come with a minimal busybox and most useful userland tools are not
> available. To add these tools back to rootfs is not convenient either.
> What's more, on some systems with runtime pm enabled, reading/writing
> registers
> from a device which is in low power state will cause problems. For these
> reasons, to have some tools/interfaces directly from kernel space via debug
> fs seems to be easy, cheap and convenient.

So, just because userspace is "hard" you want to add stuff to the kernel
instead.

Sorry, but for over the past decade, we have been doing just the
opposite, if things can be done in userspace, then they should be done
there.  So for us to go in the opposite direction, like these patches
show, would be a major change.

> These patchsets are designed to  achieve above goals to ease
> device driver and kernel debugging on embedded systems.
> 
> Rawio provides a framework to read/write registers from a bus, including
> pci, i2c, I/O device(memory mapped), etc. based on debug fs.
> Rawio bus drivers implement the read/write operation on a specific bus
> on top of the rawio framework driver.
> Currently only three bus drivers are available: pci, iomem and i2c.

You can already do this today for PCI with the UIO framework, right?
Why duplicate that functionality here with another userapce API that we
will then have to maintain for the next 40+ years?

> But it's extremely easy to add more drivers on top of the framework
> if needed.
> 
>  drivers/misc/Kconfig             |   1 +
>  drivers/misc/Makefile            |   1 +
>  drivers/misc/rawio/Kconfig       |  59 +++++
>  drivers/misc/rawio/Makefile      |   4 +
>  drivers/misc/rawio/rawio.c       | 514
> +++++++++++++++++++++++++++++++++++++++

All of your patches are line-wrapped and totally fail to apply, so even
if we wanted to take this type of changes, I couldn't :(

Have you run these proposed changes by any of the Intel kernel
developers?  What did they say to them?

If not, why haven't you, isn't that a resource you should be using for
things like this?

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/