linux-kernel - Re: [PATCH v1 3/6] driver: Google EFI SMI

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]

Date:	Thu, 27 Jan 2011 18:59:13 -0800
From:	Greg KH <greg@...ah.com>
To:	Mike Waychison <mikew@...gle.com>
Cc:	torvalds@...ux-foundation.org, San Mehat <san@...gle.com>,
	Aaron Durbin <adurbin@...gle.com>,
	Duncan Laurie <dlaurie@...gle.com>,
	linux-kernel@...r.kernel.org, Tim Hockin <thockin@...gle.com>
Subject: Re: [PATCH v1 3/6] driver: Google EFI SMI

On Wed, Jan 26, 2011 at 03:58:46PM -0800, Mike Waychison wrote:
> > Not to
> > mention the fact that you really are just adding special syscalls to the
> > system here, which is another reason people hate them.
> 
> Well, personally I like ioctls and system calls.  They don't bloat the
> system with unneeded crud and abstractions that aren't very useful.
> So what if you can't easily interface with them from a bare shell.
> That's what userland utilities are for anyhow.

Ok, but you need to document exactly what your ioctl is doing, much like
you need to document any new system calls.  That is my point, there
wasn't documentation with these new functions describing what they did
and how to use them.

Please see Documentation/ABI/ for how to add this type of information.
Yes, that's primarily used to describe sysfs files, but there's no
reason it can't describe ioctls as well.

> > So, let me ask, what specifically are you wanting to import/export
> > to/from the kernel here?  Have you thought about other kernel/user apis
> > instead of ioctls?  What is forcing you to use ioctls?
> 
> I'm not sure if you are trying to suggest that there is a better way
> to solve these problems without actually saying so.  We could probably
> use a different interface, sure.

I can't tell what you are trying to do here to determine what the best
type of interface is.

thanks,

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/