On 11/14/10 20:16, David Holland wrote:
On Sat, Nov 13, 2010 at 01:45:40AM +0900, Izumi Tsutsui wrote:
Wow. I guess you can add me to the list of people leaving.
There is no perfect world and we don't have enough resources.
Any help to keep support for ancient machines are
On 11/15/10 14:55, Johnny Billquist wrote:
On 11/14/10 20:16, David Holland wrote:
On Sat, Nov 13, 2010 at 01:45:40AM +0900, Izumi Tsutsui wrote:
Wow. I guess you can add me to the list of people leaving.
There is no perfect world and we don't have enough resources.
Any help to keep
(moving this to tech-kern because it's the right place and per request)
On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote:
Every header file should include the things it requires to compile.
Therefore, there should in principle be no cases where a header file
(or source
Every header file should include the things it requires to compile.
I've long felt this way: that, except for a very few examples like
assert.h that are defined to depend on context, the order of
#includes should not matter. In particular, if multiple files must be
included, any of them may
On Mon, Nov 15, 2010 at 03:47:32PM -0500, der Mouse wrote:
Every header file should include the things it requires to compile.
I've long felt this way: that, except for a very few examples like
assert.h that are defined to depend on context, the order of
#includes should not matter. In
I've long felt this way: that, except for a very few examples like
assert.h that are defined to depend on context, the order of
#includes should not matter. In particular, if multiple files must
be included, any of them may come first - so any file that generates
errors if it's included
On Mon, Nov 15, 2010 at 08:34:40PM +, David Holland wrote:
(moving this to tech-kern because it's the right place and per request)
On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote:
Every header file should include the things it requires to compile.
Therefore, there
On Mon, Nov 15, 2010 at 10:41:55PM +, David Laight wrote:
Indeed. Properly speaking though, headers that are exported to
userland should define only the precise symbols that userland needs;
kernel-only material should be kept elsewhere.
One start would be to add a
On Mon, Nov 15, 2010 at 03:47:32PM -0500, der Mouse wrote:
[...] just forward declarations of the structs.
(this is, btw, one of the reasons to avoid silly typedefs)
I'm not sure what typedefs have to do with it. typedeffing a name to
an incomplete (forward) struct type works just
