All of lore.kernel.org
 help / color / mirror / Atom feed
From: miquels@cistron.nl (Miquel van Smoorenburg)
To: linux-kernel@vger.rutgers.edu
Subject: Re: RLIM_INFINITY inconsistency between archs
Date: 1 Aug 2000 21:50:47 GMT	[thread overview]
Message-ID: <8m7gnn$c8k$1@enterprise.cistron.net> (raw)
In-Reply-To: 8m6vsk$er6$1@cesium.transmeta.com

In article >8m6vsk$er6$1@cesium.transmeta.com>,
H. Peter Anvin <hpa@zytor.com> wrote:
>Followup to:  <8m65np$mm3$1@enterprise.cistron.net>
>By author:    miquels@cistron.nl (Miquel van Smoorenburg)
>In newsgroup: linux.dev.kernel
>> 
>> Why? As I said you can use a glue layer. Note that you still
>> cannot mix /usr/include/net and /usr/src/linux/include/net anyway,
>> so clashes will always exist with the current system.
>> I agree it should probably be fixed.
>
>A GLUE LAYER IS FREQUENTLY NOT AN OPTION,

No need to shout, I did say I agreed with you ;)

>because you have no data
>types to carry around the semantic contents in.  You really *DO* need
>to mix both types.

Yes. So it should be fixed, right? Perhaps in 2.5 then we should
look into:

- moving kernel headers around: linux/include now contains

  o linux
  o asm
  o net
  o scsi
  o video

  To make sure we _can_ use libc headers and kernel headers we must
  eliminate clashes. linux/include/net isn't the same as /usr/include/net,
  same goes for /usr/include/scsi etc. So it's probably best to move
  everything one level to:

  o linux/kernel/*.h (this was most of linux/*.h)
  o linux/public/*.h (contains public interfaces to the kernel)
  o linux/asm/*.h
  o linux/net/*.h
  o linux/scsi/*.h
  o linux/video/*.h

  Hmm, perhaps that is not nessecary. If we're going to have a
  linux/public hierarchy, you wouldn't need the rest of the
  headers anyway, so they don't need to be moved. Cool ;)

- We need a script in /lib/modules/version/kernel-config that prints
  the CFLAGS used to compile that kernel on stdout to compile modules.

Now, I think that all of this has been mentioned before on this
list, those are not completely my ideas. Somebody mentioned marking
structures/defines/etc that need to be exported with a special
comment so that a script could generate a set of headers with the
public interfaces. That is about the same as the public/ idea,
and perhaps a bit easier, since it wouldn't annoy the hell out
of all those device driver writers that see the interface change again..

Mike.
-- 
Cistron Certified Internetwork Expert #1. Think free speech; drink free beer.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2000-08-01 21:31 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200007271459.KAA04701@tsx-prime.MIT.EDU>
     [not found] ` <200007271531.KAA89926@tomcat.admin.navo.hpc.mil>
2000-07-31 14:57   ` RLIM_INFINITY inconsistency between archs Kai Henningsen
2000-07-31 17:35     ` Richard B. Johnson
2000-07-31 20:06       ` Mike Galbraith
2000-07-31 21:15       ` Miquel van Smoorenburg
2000-07-31 21:49         ` Richard B. Johnson
2000-07-31 22:39           ` Miquel van Smoorenburg
2000-07-31 22:13         ` H. Peter Anvin
2000-07-31 22:33           ` Miquel van Smoorenburg
2000-08-01  0:17             ` H. Peter Anvin
2000-08-01  0:43               ` wingel
2000-08-01  1:00                 ` H. Peter Anvin
2000-08-01  2:06                   ` wingel
2000-08-01  9:36               ` Miquel van Smoorenburg
2000-08-01 17:03                 ` H. Peter Anvin
2000-08-01 21:50                   ` Miquel van Smoorenburg [this message]
2000-08-01  2:18           ` Mike Castle
2000-08-01  2:30             ` wingel
2000-08-01 23:55               ` Mike Castle
2000-08-02  0:18                 ` H. Peter Anvin
2000-08-02  9:28                   ` Miquel van Smoorenburg
2000-08-04  1:07                     ` H. Peter Anvin
2000-08-01 17:03             ` H. Peter Anvin
2000-08-01  2:11         ` Mike Castle
2000-08-01  9:38           ` Miquel van Smoorenburg
2000-08-01 23:44             ` Mike Castle
2000-08-02 18:16     ` peter swain
2000-07-31 17:31 Jesse Pollard
     [not found] <20000728112353Z160228-16385+645@vger.rutgers.edu>
2000-07-31 15:26 ` Kai Henningsen
2000-08-01  7:53   ` David Howells
2000-08-01 18:15     ` Kai Henningsen
2000-08-02  6:52     ` wingel
     [not found] <FyFI8n.IpM@spuddy.mew.co.uk>
2000-07-29 10:34 ` Stephen Harris
     [not found] <200007281315.OAA30398@flint.arm.linux.org.uk>
2000-07-29  1:09 ` David Howells
     [not found] <200007272122.RAA04791@tsx-prime.MIT.EDU>
     [not found] ` <m2hf9bnm95.fsf@euler.axel.nom>
     [not found]   ` <20000728162225.A4317@saw.sw.com.sg>
2000-07-29  0:51     ` Mike Castle
     [not found] <no.id>
2000-07-28 22:10 ` Adam Sampson
2000-07-28 22:20 ` Adam Sampson
2000-07-29 13:23   ` Miquel van Smoorenburg
     [not found] <3981ED0C.CBE0A0F9@transmeta.com>
2000-07-28 21:02 ` Khimenko Victor
     [not found] <Pine.LNX.4.21.0007280808460.73-100000@rc.priv.hereintown.net>
2000-07-28 20:56 ` Stuart Lynne
2000-07-28 20:13   ` clubneon
     [not found] <E13HsBT-00033e-00@the-village.bc.nu>
     [not found] ` <200007281405.JAA101655@tomcat.admin.navo.hpc.mil>
2000-07-28 14:11   ` Jamie Lokier

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='8m7gnn$c8k$1@enterprise.cistron.net' \
    --to=miquels@cistron.nl \
    --cc=linux-kernel@vger.rutgers.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.