From: "Bryan O'Sullivan" <bos@pathscale.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, openib-general@openib.org
Subject: Re: [PATCH 0 of 20] [RFC] ipath - PathScale InfiniPath driver
Date: Fri, 30 Dec 2005 17:40:50 -0800 [thread overview]
Message-ID: <1135993250.13318.94.camel@serpentine.pathscale.com> (raw)
In-Reply-To: <20051231001051.GB20314@kroah.com>
On Fri, 2005-12-30 at 16:10 -0800, Greg KH wrote:
> But we (the kernel community), don't really accept that as a valid
> reason to accept this kind of code, sorry.
Fair enough. I'd like some guidance in that case. Some of our ioctls
access the hardware more or less directly, while others do things like
read or reset counters.
Which of these kinds of operations are appropriate to retain as ioctls,
in your eyes, and which are best converted to sysfs or configfs
alternatives?
As an example, take a look at ipath_sma_ioctl. It seems to me that
receiving or sending subnet management packets ought to remain as
ioctls, while getting port or node data could be turned into sysfs
attributes. Lane identification could live in configfs. If you think
otherwise, please let me know what's more appropriate.
The less blind I am in doing these conversions, the fewer rounds we'll
have to go in reviewing humongous driver submission patches :-)
Thanks,
<b
next prev parent reply other threads:[~2005-12-31 1:40 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-29 0:31 Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 1 of 20] Introduce __memcpy_toio32 Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 2 of 20] memcpy32 for x86_64 Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 3 of 20] Add memcpy_toio32 to each arch Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 4 of 20] Define BITS_PER_BYTE Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 5 of 20] ipath - driver core header files Bryan O'Sullivan
2005-12-29 8:18 ` Pekka Enberg
2005-12-29 14:15 ` Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 6 of 20] ipath - driver debugging headers Bryan O'Sullivan
2005-12-29 8:22 ` Pekka Enberg
2005-12-29 0:31 ` [PATCH 7 of 20] ipath - MMIO copy routines Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 8 of 20] ipath - core driver, part 1 of 4 Bryan O'Sullivan
2005-12-30 8:39 ` Greg KH
2005-12-30 23:47 ` Bryan O'Sullivan
2005-12-31 0:12 ` Greg KH
2005-12-29 0:31 ` [PATCH 9 of 20] ipath - core driver, part 2 " Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 10 of 20] ipath - core driver, part 3 " Bryan O'Sullivan
2005-12-30 18:46 ` Linus Torvalds
2005-12-30 23:50 ` Bryan O'Sullivan
2005-12-31 8:36 ` Arjan van de Ven
2005-12-29 0:31 ` [PATCH 11 of 20] ipath - core driver, part 4 " Bryan O'Sullivan
2005-12-29 2:19 ` [openib-general] " Roland Dreier
2005-12-29 14:21 ` Bryan O'Sullivan
2005-12-30 8:12 ` Greg KH
2005-12-30 23:17 ` Bryan O'Sullivan
2005-12-31 0:08 ` Greg KH
2005-12-29 0:31 ` [PATCH 12 of 20] ipath - misc driver support code Bryan O'Sullivan
2005-12-30 8:25 ` Greg KH
2005-12-30 23:10 ` Bryan O'Sullivan
2005-12-31 0:13 ` Greg KH
2005-12-30 18:15 ` Arjan van de Ven
2005-12-29 0:31 ` [PATCH 13 of 20] ipath - routines used by upper layer driver code Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 14 of 20] ipath - infiniband verbs header Bryan O'Sullivan
2005-12-29 8:21 ` Pekka Enberg
2005-12-29 14:22 ` Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 15 of 20] ipath - infiniband verbs support, part 1 of 3 Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 16 of 20] path - infiniband verbs support, part 2 " Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 17 of 20] ipath - infiniband verbs support, part 3 " Bryan O'Sullivan
2005-12-29 19:24 ` Pekka Enberg
2005-12-30 3:19 ` Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 18 of 20] ipath - infiniband management datagram support Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 19 of 20] ipath - kbuild infrastructure Bryan O'Sullivan
2005-12-29 0:31 ` [PATCH 20 of 20] ipath - integrate driver into infiniband " Bryan O'Sullivan
2005-12-29 19:01 ` [PATCH 0 of 20] [RFC] ipath - PathScale InfiniPath driver Horst von Brand
2005-12-29 19:26 ` Lee Revell
2005-12-31 5:36 ` Jan Engelhardt
2006-01-02 16:05 ` Horst von Brand
2006-01-02 16:22 ` Christoph Hellwig
2005-12-30 3:17 ` Bryan O'Sullivan
2005-12-30 8:00 ` Greg KH
2005-12-30 23:11 ` Bryan O'Sullivan
2005-12-31 0:10 ` Greg KH
2005-12-31 1:40 ` Bryan O'Sullivan [this message]
2006-01-02 20:35 ` Eric W. Biederman
2006-01-02 22:22 ` Bryan O'Sullivan
2006-01-04 21:26 ` Roland Dreier
2006-01-05 15:28 ` Bryan O'Sullivan
2006-01-03 17:27 ` Greg KH
2006-01-03 20:54 ` Bryan O'Sullivan
2006-01-03 20:57 ` Arjan van de Ven
2006-01-03 21:24 ` Bryan O'Sullivan
2006-01-03 21:26 ` Arjan van de Ven
2006-01-04 3:33 ` Bryan O'Sullivan
2006-01-04 21:28 ` [openib-general] " Roland Dreier
2006-01-05 15:31 ` Bryan O'Sullivan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1135993250.13318.94.camel@serpentine.pathscale.com \
--to=bos@pathscale.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=openib-general@openib.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome