Re: Patch to teach config(8) about platforms.
On 30-Jan-2003 Benno Rice wrote:
On Thu, 2003-01-30 at 15:57, David O'Brien wrote:
On Tue, Jan 28, 2003 at 11:46:47PM -0800, Marcel Moolenaar wrote:
I would not introduce a platform/foo.h, but rather
machine/${variant}/foo.h. The reason for this is that the
/usr/include/platform directory is only needed on powerpc and mips,
which seems to indicate that it should be under machine. Also,
the use of machine/${variant} allows us to install the headers for
all variants, which may improve cross-building.
This is a very nice way of adding the complexity when it is needed, but
not getting in the way of those cases where it isn't needed.
Except that it requires us to know which platform variant directory to
use in each case. If this directory is then copied or symlinked to
/usr/include/platform or /usr/include/machine/platform, I don't object
but otherwise it'll lead to an ifdef nightmare in the machine includes.
Yeah, a platform symlink would make sense. I think /usr/include/platform
would make more sense since in the kernel you would have:
sys/foo/include (foo machine/ headers)
sys/foo/bar/include (bar platform/ headers, installed to /usr/include/machine/bar
with a /usr/include/platform symlink so that
#include platform/foo.h can easily work in both kernel
and userland)
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
Any reason why the NetBSD approach to this problem won't work? IMHO, the meta-port should drive the derived ports. The static parts of the system are radically different between the different mips platforms. Using the endian.h stuff as an example: src/sys/arch/arc/include/endian.h is just #include sys/endian.h src/sys/arch/arc/include/endian_machdep.h is #define _BYTE_ORDER _LITTLE_ENDIAN #include mips/endian_machdep.h and src/sys/arch/mips/include/endian_machdep.h is a bunch of #defines for assembler. sys/endian.h looks like: #define _LITTLE_ENDIAN 1234/* LSB first: i386, vax */ #define _BIG_ENDIAN 4321/* MSB first: 68000, ibm, net */ #define _PDP_ENDIAN 3412/* LSB first in word, MSW first in long */ #include machine/endian_machdep.h ... #include sys/cdefs.h #include sys/types.h typedef u_int32_t in_addr_t; typedef u_int16_t in_port_t; __BEGIN_DECLS uint32_thtonl __P((uint32_t)) __attribute__((__const__)); uint16_thtons __P((uint16_t)) __attribute__((__const__)); uint32_tntohl __P((uint32_t)) __attribute__((__const__)); uint16_tntohs __P((uint16_t)) __attribute__((__const__)); __END_DECLS ... (more macros/functions) In this case, there's very little duplication of effort. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
In message: [EMAIL PROTECTED] Marcel Moolenaar [EMAIL PROTECTED] writes: : general theme. Thus (in this case), ARCH=mips and MACH=algor or : MACH=sgimips... Actually, NetBSD uses MACHINE_ARCH=mipsel for little endian machines and MACHINE_ARCH=mips for big endian machines. However, it has a common set of mips include files/code, etc in src/sys/arch/mips Forcing MACHINE_ARCH to be mips in both proved too problematic. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
In message: [EMAIL PROTECTED] Marcel Moolenaar [EMAIL PROTECTED] writes: : Alpha has multiple platforms, but it has not been made explicit. : pc98 is an alternate platform for i386. And we have PowerPC and : mips. Keep in mind that for mips you have two different architectures: mipsel and mips(eb). I keep harping on this because you cannot run mipsel binaries on mipseb kernels (please ignore that some mips cpu can, in theory do this, since no free OS has climbed that mountain). You'll need different binaries (packages) for mips and mipsel. This has implcations for the kernel as well. BTW, netbsd doesn't have a 'platform' at all. Their config files have things like: machine arc mips in them. That just says make the machine symlink to src/sys/arch/arc and also make a mips symlink to src/sys/arch/mips. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Thu, Jan 30, 2003 at 10:09:57AM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Marcel Moolenaar [EMAIL PROTECTED] writes: : general theme. Thus (in this case), ARCH=mips and MACH=algor or : MACH=sgimips... Actually, NetBSD uses MACHINE_ARCH=mipsel for little endian machines and MACHINE_ARCH=mips for big endian machines. However, it has a common set of mips include files/code, etc in src/sys/arch/mips Forcing MACHINE_ARCH to be mips in both proved too problematic. Yes. I mentioned this to Juli and specifically asked if she was not going to do that. I can't recall an explicit answer. I think it was implied in the discussion at that time that it was not an option. From your other reply: Keep in mind that for mips you have two different architectures: mipsel and mips(eb). I keep harping on this because you cannot run mipsel binaries on mipseb kernels (please ignore that some mips cpu can, in theory do this, since no free OS has climbed that mountain). You'll need different binaries (packages) for mips and mipsel. Good point. The toolchain configuration is related to this. We now select on MACHINE_ARCH, which would not capture the endianness if it was encoded in MACHINE. Granted, we could include MACHINE in the selection of the BFD and code generator files, but the patch did not include that. I still don't reject MIPS as the architecture and have the variants as sub-concepts, but we do need to discuss in that case how it's going to work. The packaging automaticly adds to the dimension of the problem. If variants have the same endianness and share a common runtime, you would like to be able to share packages between the variants. But if the endianness differs or the runtime is different, this cannot happen. If in both cases we talk about platform then I think our abstraction is inadequate. Given that NetBSD is known to be able to run on your toaster (it would on mine if I had one :-), it would be a mistake to reject their mechanism without fully understanding what it is we're rejecting. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Marcel Moolenaar [EMAIL PROTECTED] writes: : Alpha has multiple platforms, but it has not been made explicit. : pc98 is an alternate platform for i386. And we have PowerPC and : mips. Keep in mind that for mips you have two different architectures: mipsel and mips(eb). I keep harping on this because you cannot run mipsel binaries on mipseb kernels (please ignore that some mips cpu can, in theory do this, since no free OS has climbed that mountain). You'll need different binaries (packages) for mips and mipsel. PPC has this same thing: byte order is controlled in software. The normal thing to do for this is to pick one true byte order, but then you may lose access to the host system software that may otherwise be possible to run in binary compatability mode. Actually, as part of the task switch code, it's possible to switch orders on a per task basis, or even run the kernel in one order, and user tasks in another (given appropriate wrapping of the system call arguments which are larger than a byte). My general recommendation for the PPC, actually, is network byte order (Motorolla byte order), since if you are running something manufactured before the PPC620 chip, you actually pay a penalty in performance for running Intel byte order. I never got hold of any documentation claims, one way or the other, for the MIPS, on which order it prefers, or if it actually doesn't have a preference, like older PPC processors. That said, the point about needing a different userland is really one about binary compatability, and how hard your willing to work in order to achieve it, or if you care at all (e.g. the DEC systems ran in VAX byte order, which is Intel byte order, but you aren't going to be able to run Ultrix programs in an emulator, without an incredible amount of effort and/or pirating library files). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Wed, 2003-01-29 at 18:46, Marcel Moolenaar wrote:
On Wed, Jan 29, 2003 at 05:32:51PM +1100, Benno Rice wrote:
Agreed. There's an advantage there, but see also my reply to
Juli about the use of machine to mean MACHINE_ARCH and the
use of platform to mean MACHINE. This I don't find appealing.
I can see your point here, but if needed I'd rather see them renamed to
MACHINE (which maps to the current MACHINE_ARCH) and PLATFORM as MACHINE
and MACHINE_ARCH are confusingly similar.
I'm not sure I understand you. I don't mind the capitalization,
just that we have MACHINE_ARCH and MACHINE defined on the hand
and machine and platform on the other. If you would ask a
person how they should be related, I can imagine that the
logical should would be to relate machine to MACHINE and
platform to MACHINE_ARCH. Which is opposite to what Juli
proposed. That's the unappealing part. Not a biggy, but
something that's better avoided now than fixed later.
In that case I'm mostly in agreement. Avoiding confusion is a Good
Thing(tm).
[snip]
Agreed. We should not do the same, but instead of saying that we
do mips and powerpc different, I think we should say that mips and
powerpc do it the normal way and pc98 does it differently. I like
to use an extra keyword for the weird case (pc98) and not the normal
(common) case. See also above, this is looking at it from a point
of view we'll going to have in the future, not a point of view
we all have now.
Ok, so are you saying here that Juli's patch is ok but we need to look
at how we deal with pc98?
I would not introduce a platform/foo.h, but rather
machine/${variant}/foo.h. The reason for this is that the
/usr/include/platform directory is only needed on powerpc and mips,
which seems to indicate that it should be under machine. Also,
the use of machine/${variant} allows us to install the headers for
all variants, which may improve cross-building. Note that I haven't
tried it on for size, so I'm not fixated on it. I was hoping this
would fall out of the discussion.
You see how the current approach affects other architectures if you
look at the diff for src/sys/conf/kmod.mk. All architectures,
including those that don't have multiple variants will have a link
added that mirrors the machine link. I find that aestheticly
displeasing. If you have the variants under machine, you don't
have to create more links.
The change to src/include/Makefile also seems to have a bug in
that it depends in /usr/include/platform to be created by
mtree, but I don't see and diff for that. Adding platform to
BSD.include.dist means that every architecture gets the
directory. Otherwise it has to be created by hand for those
platforms that have it.
The same happens in config(8) where we create a platform link
in all cases, not just for powerpc and mips.
Ok, the nice side to having platform/foo.h is that (to go back to the
endian example) you can have machine/endian.h including
platform/endian.h and not having to be a mess like:
#if defined(POWERMAC)
#include machine/powermac/endian.h
#elsif defined(LITTLE_ENDIAN_ARCH)
#include machine/little_endian_arch/endian.h
#elsif
...
#endif
It doesn't have to be /usr/include/platform, it could be
/usr/include/machine/platform for instance, but it'd be nice for it to
have a constant name.
Or are you saying that you would prefer to change how the machine
directive works in config(8) and introduce a new non-standard
directive for pc98?
That was the thought I was playing with.
Hmm. Juli, what do you think of this?
We could perhaps introduce platform and make it mutually exclusive
with machine, and that way if the config file has a machine
directive we get the old behaviour and only invoke the new behaviour
when we have a platform directive. Then we can start transitioning
over to it as needed. This is pretty much a no-op on sparc64, ia64 and
alpha (AFAIK) but powerpc can switch, and i386/pc98 can switch to it
later on. Perhaps this could be a target for 6.0.
If the former, I agree totally. If the latter, I'm not so sure. I'd
rather see the directive be platform as that is a much more accurate
name for it IMO. If this means we kill off the machine directive, then
that may be how it works.
I don't have a problem with the name platform, although I avoid it
for now to avoid confusion.
*nod* Fair enough.
--
Benno Rice [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 11:56:59PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] You see how the current approach affects other architectures if you look at the diff for src/sys/conf/kmod.mk. All architectures, including those that don't have multiple variants will have a link added that mirrors the machine link. I find that aestheticly displeasing. If you have the variants under machine, you don't have to create more links. Only within the kernel build directory. That's at Peter's request. Doing it for the installed version breaks mkioctl. But not doing it makes the installed version rather useless on mips and powerpc, doesn't it? I mean, not having the links to the platform directory when headers in the machine directory depend on it? Or am I missing the purpose of the installed bsd.kmod.mk? The same happens in config(8) where we create a platform link in all cases, not just for powerpc and mips. See the comment for kmod.mk. It doesn't affect anything. It can be changed, if you like. It depends. If we opt for a platform directory in all case, we might as well have the link in all cases. I don't like it, but won't actually wake up every morning and go look for it in an attempt to make my SM life more enjoyable :-) -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Wed, Jan 29, 2003 at 07:19:38PM +1100, Benno Rice wrote: The same happens in config(8) where we create a platform link in all cases, not just for powerpc and mips. Ok, the nice side to having platform/foo.h is that (to go back to the endian example) you can have machine/endian.h including platform/endian.h and not having to be a mess like: #if defined(POWERMAC) #include machine/powermac/endian.h #elsif defined(LITTLE_ENDIAN_ARCH) #include machine/little_endian_arch/endian.h #elsif ... #endif It doesn't have to be /usr/include/platform, it could be /usr/include/machine/platform for instance, but it'd be nice for it to have a constant name. Agreed. A link is better. Or are you saying that you would prefer to change how the machine directive works in config(8) and introduce a new non-standard directive for pc98? That was the thought I was playing with. Hmm. Juli, what do you think of this? We could perhaps introduce platform and make it mutually exclusive with machine, and that way if the config file has a machine directive we get the old behaviour and only invoke the new behaviour when we have a platform directive. Then we can start transitioning over to it as needed. This is pretty much a no-op on sparc64, ia64 and alpha (AFAIK) but powerpc can switch, and i386/pc98 can switch to it later on. Perhaps this could be a target for 6.0. What if an architecture doesn't have different platforms. Do we want to give a platform name that matches the architecture or do we make platform optional? I think I prefer it to be optional. This could mean we have a kernel config file that has no machine and not platform keyword. I've been thinking about the implicit selection of the architecture based on where the config file lives. We currently restrict where config(8) can be run from and don't really have a nice way of dealing with the case where SYSTEM_NAME is actually a path. This basicly means that we must run config(8) from /sys/$ARCH/conf. This makes the implicit selection of the architecture logical, even or especially if we want to remove the restriction of where we have the kernel config file and/or where we run the config(8) utility from later. We can always add the necessary options and keywords to deal with the added flexibility, including making the architecture explicit. In that case it would work the same on all architectures without any weird interferences of having multiple platforms. Thoughts? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On 29-Jan-2003 Benno Rice wrote: On Wed, 2003-01-29 at 18:46, Marcel Moolenaar wrote: On Wed, Jan 29, 2003 at 05:32:51PM +1100, Benno Rice wrote: Agreed. There's an advantage there, but see also my reply to Juli about the use of machine to mean MACHINE_ARCH and the use of platform to mean MACHINE. This I don't find appealing. I can see your point here, but if needed I'd rather see them renamed to MACHINE (which maps to the current MACHINE_ARCH) and PLATFORM as MACHINE and MACHINE_ARCH are confusingly similar. I'm not sure I understand you. I don't mind the capitalization, just that we have MACHINE_ARCH and MACHINE defined on the hand and machine and platform on the other. If you would ask a person how they should be related, I can imagine that the logical should would be to relate machine to MACHINE and platform to MACHINE_ARCH. Which is opposite to what Juli proposed. That's the unappealing part. Not a biggy, but something that's better avoided now than fixed later. In that case I'm mostly in agreement. Avoiding confusion is a Good Thing(tm). Just be consistent please. Ignore the implementation and choose one of these two paths: 1) Use MACHINE and MACHINE_ARCH with MACHINE_ARCH being the architecture and MACHINE being the platform and use the 'machine' keyword for MACHINE with MACHINE_ARCH either explicit (in which case 'machine' defaults to 'arch' just like MACHINE defaults to MACHINE_ARCH) or implicit from the config file location. 2) Use PLATFORM and MACHINE with matching config keywords and if platform is not specified it defaults to MACHINE. I don't really care which, but please just pick one and be fully consistent. If you go with 1), I suggest an alternative header file layout where you have an /usr/include/arch and the machine/ headers (which are platform-specific) include the arch/ headers for common things. I think both ways can work, but please do not change the meaning of one set w/o changing the other. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Wed, Jan 29, 2003 at 07:19:38PM +1100, Benno Rice wrote: Or are you saying that you would prefer to change how the machine directive works in config(8) and introduce a new non-standard directive for pc98? That was the thought I was playing with. Hmm. Juli, what do you think of this? We could perhaps introduce platform and make it mutually exclusive with machine, and that way if the config file has a machine directive we get the old behaviour and only invoke the new behaviour when we have a platform directive. Then we can start transitioning over to it as needed. This is pretty much a no-op on sparc64, ia64 and alpha (AFAIK) but powerpc can switch, and i386/pc98 can switch to it later on. Perhaps this could be a target for 6.0. What if an architecture doesn't have different platforms. Do we want to give a platform name that matches the architecture or do we make platform optional? I think I prefer it to be optional. This could mean we have a kernel config file that has no machine and not platform keyword. Well, the whole point of platform is it doesn't affect first-class platforms, which is where we have one architecture, one platform. In those cases it would gain nothing, and by not having it, there is no loss. Of course, i386 might eventually grow it, if pc98 is merged, as there may be some things we would restrict to the !pc98 case. But hell, at that point we may have platform isa and platform acpi or something, for the two different growing i386 platforms. I suppose jhb might prefer legacy for the former :) I've been thinking about the implicit selection of the architecture based on where the config file lives. We currently restrict where config(8) can be run from and don't really have a nice way of dealing with the case where SYSTEM_NAME is actually a path. This basicly means that we must run config(8) from /sys/$ARCH/conf. This makes the implicit selection of the architecture logical, even or especially if we want to remove the restriction of where we have the kernel config file and/or where we run the config(8) utility from later. We can always add the necessary options and keywords to deal with the added flexibility, including making the architecture explicit. In that case it would work the same on all architectures without any weird interferences of having multiple platforms. If we just make machine mean more of what it means now, then we're set. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: John Baldwin [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On 29-Jan-2003 Benno Rice wrote: On Wed, 2003-01-29 at 18:46, Marcel Moolenaar wrote: On Wed, Jan 29, 2003 at 05:32:51PM +1100, Benno Rice wrote: Agreed. There's an advantage there, but see also my reply to Juli about the use of machine to mean MACHINE_ARCH and the use of platform to mean MACHINE. This I don't find appealing. I can see your point here, but if needed I'd rather see them renamed to MACHINE (which maps to the current MACHINE_ARCH) and PLATFORM as MACHINE and MACHINE_ARCH are confusingly similar. I'm not sure I understand you. I don't mind the capitalization, just that we have MACHINE_ARCH and MACHINE defined on the hand and machine and platform on the other. If you would ask a person how they should be related, I can imagine that the logical should would be to relate machine to MACHINE and platform to MACHINE_ARCH. Which is opposite to what Juli proposed. That's the unappealing part. Not a biggy, but something that's better avoided now than fixed later. In that case I'm mostly in agreement. Avoiding confusion is a Good Thing(tm). Just be consistent please. Ignore the implementation and choose one of these two paths: 1) Use MACHINE and MACHINE_ARCH with MACHINE_ARCH being the architecture and MACHINE being the platform and use the 'machine' keyword for MACHINE with MACHINE_ARCH either explicit (in which case 'machine' defaults to 'arch' just like MACHINE defaults to MACHINE_ARCH) or implicit from the config file location. 2) Use PLATFORM and MACHINE with matching config keywords and if platform is not specified it defaults to MACHINE. I don't really care which, but please just pick one and be fully consistent. If you go with 1), I suggest an alternative header file layout where you have an /usr/include/arch and the machine/ headers (which are platform-specific) include the arch/ headers for common things. I think both ways can work, but please do not change the meaning of one set w/o changing the other. If we change the meaning of machine, IMO the requirement to include up to *every* exported header with a stub is ugly. NetBSD does this. What if we install them as they're named. arch for the multi-arch systems, platform too... And symlink machine to arch for backwards compatability? I have to think that a complete move to a new pair of words would be GREAT, but we'd want to maintain some (faked) historic mistakes :) Unless you think that the platform headers should be the consumers, but of course, then you'd want to invert how the build, etc., are in what I'm suggesting, or? I mean, a lot of this is out of wanting the master port to drive, with the meta-data in the back, reading off the map, as it were. Aside from that, a pair of arch and platform would be good, and have them be mutually exclusive with machine where machine is for the traditional 1:1 ports. And retains the old behaviour, modulo any possible new stuff wrt config file location that arch would give us flexibility on. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Wed, Jan 29, 2003 at 11:55:42AM -0800, Juli Mallett wrote: What if an architecture doesn't have different platforms. Do we want to give a platform name that matches the architecture or do we make platform optional? I think I prefer it to be optional. This could mean we have a kernel config file that has no machine and not platform keyword. Well, the whole point of platform is it doesn't affect first-class platforms, which is where we have one architecture, one platform. I think the number of first-class platforms is less than you think At this time only ia64 and sparc64 would fit, with ia64 having a high chance of growing another platform... Alpha has multiple platforms, but it has not been made explicit. pc98 is an alternate platform for i386. And we have PowerPC and mips. So, I look at it from the opposite way. The 1A, 1P case is a special' case of 1A, nP, for any reasonable number n ;-) 1A = one architecture, 1P = one platform, nP = multiple platforms, where n = the number of platforms. Designing it such that it's good for any number n of platforms yields a system that more easily captures the exception of n=1. Trying to handle the n1 case in a system that's primarily designed to handle n=1 is much harder. You can say that pc98 is the result of trying to handle n1 in a system that can only work with n=1. In those cases it would gain nothing, and by not having it, there is no loss. Of course, i386 might eventually grow it, if pc98 is merged, as there may be some things we would restrict to the !pc98 case. But hell, at that point we may have platform isa and platform acpi or something, for the two different growing i386 platforms. I suppose jhb might prefer legacy for the former :) What about IO_APIC vs PIC? The point is not that we're discussing whether or not they should be platforms, but that in a weird way one could treat it as different platforms. If we can handle such a case then nothing is lost if we don't make use of it for i386. If we just make machine mean more of what it means now, then we're set. But pc98 needs to be dealt with. Maybe a summary of what's been discussed would be a good idea. We've had a lot of mail with some confusion to be dealt with as well... -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] If we just make machine mean more of what it means now, then we're set. But pc98 needs to be dealt with. Maybe a summary of what's been discussed would be a good idea. We've had a lot of mail with some confusion to be dealt with as well... Well, yes and no... If we make machine mean more of where stuff is which is what it means now, then we can have machine pc98 for it, until it moves to the new world order (if ever) and use that to figure out where files,options,ldscript,... And so on, fine. It obviously already does the right thing wrt MACHINE_ARCH for how things work. Those are defined by the native system's headers when make is built. And for a cross-build, they're overridden. So if we just add that one tiny little bit of logic to end up with /sys/$machine (for config), then pc98 is fine even wrt being able to build outside of the source tree... Can you tell me where pc98 is a problem here? Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Wed, Jan 29, 2003 at 12:55:30PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] If we just make machine mean more of what it means now, then we're set. But pc98 needs to be dealt with. Maybe a summary of what's been discussed would be a good idea. We've had a lot of mail with some confusion to be dealt with as well... Well, yes and no... If we make machine mean more of where stuff is which is what it means now, then we can have machine pc98 for it, until it moves to the new world order (if ever) and use that to figure out where files,options,ldscript,... And so on, fine. It obviously already does the right thing wrt MACHINE_ARCH for how things work. Those are defined by the native system's headers when make is built. And for a cross-build, they're overridden. So if we just add that one tiny little bit of logic to end up with /sys/$machine (for config), then pc98 is fine even wrt being able to build outside of the source tree... Can you tell me where pc98 is a problem here? I thought the idea was to have machine be usable for platforms, so as to have the mapping machine-MACHINE. This makes the keyword unusable for handling the pc98 case. I guess I was confused (now you know who needs the summary :-) -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Wed, Jan 29, 2003 at 12:55:30PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-29 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] If we just make machine mean more of what it means now, then we're set. But pc98 needs to be dealt with. Maybe a summary of what's been discussed would be a good idea. We've had a lot of mail with some confusion to be dealt with as well... Well, yes and no... If we make machine mean more of where stuff is which is what it means now, then we can have machine pc98 for it, until it moves to the new world order (if ever) and use that to figure out where files,options,ldscript,... And so on, fine. It obviously already does the right thing wrt MACHINE_ARCH for how things work. Those are defined by the native system's headers when make is built. And for a cross-build, they're overridden. So if we just add that one tiny little bit of logic to end up with /sys/$machine (for config), then pc98 is fine even wrt being able to build outside of the source tree... Can you tell me where pc98 is a problem here? I thought the idea was to have machine be usable for platforms, so as to have the mapping machine-MACHINE. This makes the keyword unusable for handling the pc98 case. I guess I was confused (now you know who needs the summary :-) Well, I like what jhb has suggested, of fully moving to a new set of keywords for config(8) to describe these sorts of things, rather than having machine+platform, having arch+platform, but keeping machine for those things that want it. Does that work for you? That way there's no misunderstanding about machine as it comes out of the picture, except for cases where MACHINE_ARCH is MACHINE is machine, unless we are making the (unaffected) pc98 mistake. When I mean make machine more of what it is now, I mean just use it for finding stuff, which is all it does now. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Wed, Jan 29, 2003 at 01:28:33PM -0800, Juli Mallett wrote: I thought the idea was to have machine be usable for platforms, so as to have the mapping machine-MACHINE. This makes the keyword unusable for handling the pc98 case. I guess I was confused (now you know who needs the summary :-) Well, I like what jhb has suggested, of fully moving to a new set of keywords for config(8) to describe these sorts of things, rather than having machine+platform, having arch+platform, but keeping machine for those things that want it. Does that work for you? Yes. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 08:13:22PM -0500, Mike Barcroft wrote: Benno Rice [EMAIL PROTECTED] writes: On Wed, 2003-01-29 at 11:18, Juli Mallett wrote: * De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] In short, platform provides machinery for a single port of FreeBSD which represents exactly one MACHINE_ARCH to support a numbe of different hardware platforms - MACHINE - under a unified system, without interfering with how anything works, and without doing it in a convoluted/imho-backwards way. There is not a way to mix MACHINE and MACHINE_ARCH within a single port, as it is now. You have to duplicate things like pc98 does. I'd also like to point out that PowerPC will benefit greatly from this. PowerPC platforms vary wildly in how they do various things (incl. endianness in some cases) and so this provides a much cleaner mechanism to select a set of platform quirks than trying to do what i386/pc98 do. Perhaps if we could see PC98 converted to this design the advantages would become obvious. I think this is an EXCELLENT idea! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 11:46:47PM -0800, Marcel Moolenaar wrote:
I would not introduce a platform/foo.h, but rather
machine/${variant}/foo.h. The reason for this is that the
/usr/include/platform directory is only needed on powerpc and mips,
which seems to indicate that it should be under machine. Also,
the use of machine/${variant} allows us to install the headers for
all variants, which may improve cross-building.
This is a very nice way of adding the complexity when it is needed, but
not getting in the way of those cases where it isn't needed.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
David O'Brien wrote: On Tue, Jan 28, 2003 at 09:37:16PM -0800, Juli Mallett wrote: I've made a note that you don't think my way is optimal. I do, and that's that, at this point. No black magic, no convoluted config files, etc. Go deal with the ODE config and Mach's configuration files, I have. Or NetBSD's. Or OpenBSD's. At this point, I am convinced that the platform keyword is the least offensive and most productive way of doing all of this, and so on, being someone who has worked with more backwards methods, and being the person who had to deal with this first, and came up with something that suits the two groups who need it most (the pc98 mistake is probably near impossible to correct, due to the historical nature), MIPS, and PowerPC. Juli, you need to convince many more than just yourself that this is a good approach for something that is so over-reaching and will be something we *all* have to live with. Right now you don't have much of a buy-in for this, and we haven't even seen public support for it from Peter (the config(8) maintainer). I still think a PC98 conversion would be compelling. But in any case, isn't the first person to a working PPC port kind of an overriding argument, one way or the other? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Thu, 2003-01-30 at 15:48, David O'Brien wrote: On Tue, Jan 28, 2003 at 09:37:16PM -0800, Juli Mallett wrote: I've made a note that you don't think my way is optimal. I do, and that's that, at this point. No black magic, no convoluted config files, etc. Go deal with the ODE config and Mach's configuration files, I have. Or NetBSD's. Or OpenBSD's. At this point, I am convinced that the platform keyword is the least offensive and most productive way of doing all of this, and so on, being someone who has worked with more backwards methods, and being the person who had to deal with this first, and came up with something that suits the two groups who need it most (the pc98 mistake is probably near impossible to correct, due to the historical nature), MIPS, and PowerPC. Juli, you need to convince many more than just yourself that this is a good approach for something that is so over-reaching and will be something we *all* have to live with. Right now you don't have much of a buy-in for this, and we haven't even seen public support for it from Peter (the config(8) maintainer). Possibly you have a very eloquent design, and that once something is implemented using it the rest of us will have our light bulbs turned on. Maybe this is something that should remain in a Perforce tree until that time. I actually think this design is a good thing. I look at the way NetBSD does sub-ports and I find it mildly confusing unless you know a port is a sub-port of one of the top-level ports (eg, macppc's relationship to powerpc) it looks like it's a top-level port in it's own right. This system would allow us to group all the sub-ports in the same directory, thus clearly showing the relationship. I would like to see the framework for this brought in, then when I start work on making FreeBSD work on the Teron CX boards I can use it. We can also aim (if we wish) to move pc98 over to this. Alpha could also use this to separate out the various platforms and we could also use it to distinguish between acpi and legacy PC systems if we want. By rejecting this, you're forcing powerpc platform ports (of which there will be more than one, I can assure you) to do pc98-style hackery in order to exist. I really don't want this. It's my aim with the powerpc port to enable vendors to support their hardware with a minimum of effort. This means making adding new platforms easy and quick. Juli's system allows this. The current system doesn't. -- Benno Rice [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Patch to teach config(8) about platforms.
On Thu, 2003-01-30 at 15:57, David O'Brien wrote:
On Tue, Jan 28, 2003 at 11:46:47PM -0800, Marcel Moolenaar wrote:
I would not introduce a platform/foo.h, but rather
machine/${variant}/foo.h. The reason for this is that the
/usr/include/platform directory is only needed on powerpc and mips,
which seems to indicate that it should be under machine. Also,
the use of machine/${variant} allows us to install the headers for
all variants, which may improve cross-building.
This is a very nice way of adding the complexity when it is needed, but
not getting in the way of those cases where it isn't needed.
Except that it requires us to know which platform variant directory to
use in each case. If this directory is then copied or symlinked to
/usr/include/platform or /usr/include/machine/platform, I don't object
but otherwise it'll lead to an ifdef nightmare in the machine includes.
--
Benno Rice [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: Patch to teach config(8) about platforms.
In article [EMAIL PROTECTED]
Juli Mallett [EMAIL PROTECTED] writes:
For example platform sgimips implies
options SGIMIPS. Below are patches to makefile glue and config(8)
itself.
I think that using '#ifdef machine' (like #ifdef PC98) is not a good
idea. If it requires, the file should be splited into sys/machine.
I'll split some files in sys/i386 into sys/pc98.
For clarity, this is used in cases where the platform may define its
own values that a header needs, and as such, you might see something
in machine/endian.h like:
#include platform/endian.h
How about next way?
- Install sys/${MACHINE}/include into /usr/include/${MACHINE}
- Symlink /usr/include/machine - /usr/include/${MACHINE}
- If ${MACHINE} != ${MACHINE_ARCH},
install sys/${MACHINE_ARCH}/include into /usr/include/${MACHINE_ARCH}
For example, sys/pc98/include/endian.h is '#include i386/endian.h'
only.
---
TAKAHASHI Yoshihiro [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Takahashi Yoshihiro [EMAIL PROTECTED] [ Data: 2003-01-28 ]
[ Subjecte: Re: Patch to teach config(8) about platforms. ]
In article [EMAIL PROTECTED]
Juli Mallett [EMAIL PROTECTED] writes:
For example platform sgimips implies
options SGIMIPS. Below are patches to makefile glue and config(8)
itself.
I think that using '#ifdef machine' (like #ifdef PC98) is not a good
idea. If it requires, the file should be splited into sys/machine.
I'll split some files in sys/i386 into sys/pc98.
For clarity, this is used in cases where the platform may define its
own values that a header needs, and as such, you might see something
in machine/endian.h like:
#include platform/endian.h
How about next way?
- Install sys/${MACHINE}/include into /usr/include/${MACHINE}
- Symlink /usr/include/machine - /usr/include/${MACHINE}
- If ${MACHINE} != ${MACHINE_ARCH},
install sys/${MACHINE_ARCH}/include into /usr/include/${MACHINE_ARCH}
For example, sys/pc98/include/endian.h is '#include i386/endian.h'
only.
This approach is a really bad one architecturally, in my opinion. It means
there is a lot of duplication of what may all be VERY similar, and it means
that if we had say 5 platforms supported by the MIPS port (certainly this is
not a high number at all) that means there would be 5 directories under
src/sys... And none of them would be mips since we wouldn't be supporting
any hardware called mips, that's just the general architecture.
Or maybe we'd have mips and it would just be the first machine we ported
to, and so that would be even more confusing for people trying to do a clean
port to *just* support their architecture. They would have to know the other
hardware very well also, not just the MIPS stuff, so they would know what to
remove, what was something FreeBSD needed on MIPS, etc.
I just really would like things to be clean, and abstracted, and not waste
anyone's time. Why should we have to duplicate so much code?
Thanx,
juli.
--
Juli Mallett [EMAIL PROTECTED]
AIM: BSDFlata -- IRC: juli on EFnet
OpenDarwin, Mono, FreeBSD Developer
ircd-hybrid Developer, EFnet addict
FreeBSD on MIPS-Anything on FreeBSD
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
[sorry -- dropping in the middle of the thread] On Tue, Jan 28, 2003 at 12:08:30PM -0800, Juli Mallett wrote: This approach is a really bad one architecturally, in my opinion. It means there is a lot of duplication of what may all be VERY similar, and it means that if we had say 5 platforms supported by the MIPS port (certainly this is not a high number at all) that means there would be 5 directories under src/sys... And none of them would be mips since we wouldn't be supporting any hardware called mips, that's just the general architecture. I tend to agree. I just really would like things to be clean, and abstracted, and not waste anyone's time. Why should we have to duplicate so much code? I'm not sure platform is the answer. We already have the distinction between MACHINE_ARCH and MACHINE and it looks to me that MACHINE can do what you try to achieve with platform. Why add a platform keyword to config(8) if we already have the machine keyword? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] I just really would like things to be clean, and abstracted, and not waste anyone's time. Why should we have to duplicate so much code? I'm not sure platform is the answer. We already have the distinction between MACHINE_ARCH and MACHINE and it looks to me that MACHINE can do what you try to achieve with platform. Why add a platform keyword to config(8) if we already have the machine keyword? Because that requires us to do what pc98 does, which is to have the meta-port be the master port, and include up into the arch-port, and that means that either you have every header in the arch-port be wrapped by the meta-port, as machine is the meta-port, or you just copy everything and make local changes. IMHO the right thing to do is have a meta-port be meta-data under the master (arch) port, as opposed to having a hell of a lot of meta-ports driving and duplicating a lot from the arch-port, at least in the files list, if not in a gamillion other places. Generic endianness related information. sys/endian.h -- Implementations of swapping routines, etc., for this architecture, among other things. machine/endian.h -- Defines the endianness of this platform. platform/endian.h Early cpu startup machine_arch::locore.s::_start -- Set up things in C that are early. machine_arch::machdep.c::mach_init -- Set up hardware for this platform we need early (e.g. console, bootstrap vector, etc.) machine::machdep_machine.c::platform_init -- Continue with slightly later CPU startup... -- Call out to MI startup... -- Do that thing you do. kern::kern_main.c::mi_startup config GENERIC -- files.machine_arch -- enable standard things enable platform things -- -- make platform symlink build Etc. Follow my logic? Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 03:17:49PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] I just really would like things to be clean, and abstracted, and not waste anyone's time. Why should we have to duplicate so much code? I'm not sure platform is the answer. We already have the distinction between MACHINE_ARCH and MACHINE and it looks to me that MACHINE can do what you try to achieve with platform. Why add a platform keyword to config(8) if we already have the machine keyword? Because that requires us to do what pc98 does, which is to have the meta-port be the master port, and include up into the arch-port, and that means that either you have every header in the arch-port be wrapped by the meta-port, as machine is the meta-port, or you just copy everything and make local changes. I'm sorry, you use implications I don't see to come to a conclusion I don't get: Start with the beginning: We have MACHINE_ARCH and MACHINE. Can you represent the problem you're seeing with MIPS with two entities, namely MACHINE_ARCH and MACHINE? If yes, how exactly do these entities need to be defined in that case and how do they relate to each other. If no, explain why you need more entities to capture the problem. No implementation details please. Subsequent questions (if required) will be posted based on the answer given to this one. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Tue, Jan 28, 2003 at 03:17:49PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] I just really would like things to be clean, and abstracted, and not waste anyone's time. Why should we have to duplicate so much code? I'm not sure platform is the answer. We already have the distinction between MACHINE_ARCH and MACHINE and it looks to me that MACHINE can do what you try to achieve with platform. Why add a platform keyword to config(8) if we already have the machine keyword? Because that requires us to do what pc98 does, which is to have the meta-port be the master port, and include up into the arch-port, and that means that either you have every header in the arch-port be wrapped by the meta-port, as machine is the meta-port, or you just copy everything and make local changes. I'm sorry, you use implications I don't see to come to a conclusion I don't get: Start with the beginning: We have MACHINE_ARCH and MACHINE. Can you represent the problem you're seeing with MIPS with two entities, namely MACHINE_ARCH and MACHINE? If yes, how exactly do these entities need to be defined in that case and how do they relate to each other. If no, explain why you need more entities to capture the problem. Sure, say we support sgimips and algor MACHINE's on the mips MACHINE_ARCH. That's SGI workstations, which are big-endian and have ARCBIOS stuff, and Algorithmics development boards, which support little-endian and big-endian configurations. Obviously we have machine mips, right? But that determines what machine is a link to, and files.machine that is read. So that means that we need to have machine/*.h stubbed in both algor/ and sgimips/. Each of those defines the things they need to be defined, and then includes mips/\.h. Even if we know that we never need to have any changes, or otherwise have the abstraction the wrong way around. It also means that you have to pull in the mips options and files list for both of those ports, and so on. So you end up having machine $(MACHINE) and having to explicitly inherit bit by bit everything that you may need into the meta-port (algor or sgimips -- $(MACHINE)), in an explicit manner. My way, machine is mips and the headers which provide tunables include platform/\.h. Optional hardware for a given platform is pulled in via files.mips optional directives. Everything is less convoluted, IMHO. No implementation details please. I did my best, but I still have to show that there are two explicit meta-ports. My previous email had no implementation details, just general structure, and you rejected it, so I hope this is better. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] In short, platform provides machinery for a single port of FreeBSD which represents exactly one MACHINE_ARCH to support a numbe of different hardware platforms - MACHINE - under a unified system, without interfering with how anything works, and without doing it in a convoluted/imho-backwards way. There is not a way to mix MACHINE and MACHINE_ARCH within a single port, as it is now. You have to duplicate things like pc98 does. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Wed, 2003-01-29 at 11:18, Juli Mallett wrote: * De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] In short, platform provides machinery for a single port of FreeBSD which represents exactly one MACHINE_ARCH to support a numbe of different hardware platforms - MACHINE - under a unified system, without interfering with how anything works, and without doing it in a convoluted/imho-backwards way. There is not a way to mix MACHINE and MACHINE_ARCH within a single port, as it is now. You have to duplicate things like pc98 does. I'd also like to point out that PowerPC will benefit greatly from this. PowerPC platforms vary wildly in how they do various things (incl. endianness in some cases) and so this provides a much cleaner mechanism to select a set of platform quirks than trying to do what i386/pc98 do. -- Benno Rice [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 04:09:36PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Tue, Jan 28, 2003 at 03:17:49PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] I just really would like things to be clean, and abstracted, and not waste anyone's time. Why should we have to duplicate so much code? I'm not sure platform is the answer. We already have the distinction between MACHINE_ARCH and MACHINE and it looks to me that MACHINE can do what you try to achieve with platform. Why add a platform keyword to config(8) if we already have the machine keyword? Because that requires us to do what pc98 does, which is to have the meta-port be the master port, and include up into the arch-port, and that means that either you have every header in the arch-port be wrapped by the meta-port, as machine is the meta-port, or you just copy everything and make local changes. I'm sorry, you use implications I don't see to come to a conclusion I don't get: Start with the beginning: We have MACHINE_ARCH and MACHINE. Can you represent the problem you're seeing with MIPS with two entities, namely MACHINE_ARCH and MACHINE? If yes, how exactly do these entities need to be defined in that case and how do they relate to each other. If no, explain why you need more entities to capture the problem. Sure, say we support sgimips and algor MACHINE's on the mips MACHINE_ARCH. That's SGI workstations, which are big-endian and have ARCBIOS stuff, and Algorithmics development boards, which support little-endian and big-endian configurations. Obviously we have machine mips, right? Hmmm... No so obvious. I would expect MACHINE_ARCH to be MIPS, which is implied by the implementation (ie /sys/mips; /sys/conf/files.mips) This leaves the machine keyword in the kernel config file free to be used for the platform/implementation. But that determines what machine is a link to, and files.machine that is read. So that means that we need to have machine/*.h stubbed in both algor/ and sgimips/. Each of those defines the things they need to be defined, and then includes mips/\.h. Even if we know that we never need to have any changes, or otherwise have the abstraction the wrong way around. It also means that you have to pull in the mips options and files list for both of those ports, and so on. So you end up having machine $(MACHINE) and having to explicitly inherit bit by bit everything that you may need into the meta-port (algor or sgimips -- $(MACHINE)), in an explicit manner. My way, machine is mips and the headers which provide tunables include platform/\.h. Optional hardware for a given platform is pulled in via files.mips optional directives. Everything is less convoluted, IMHO. No implementation details please. I did my best, but I still have to show that there are two explicit meta-ports. My previous email had no implementation details, just general structure, and you rejected it, so I hope this is better. It's different :-) What I'm trying to get at is how sgimips is the same as algor and likewise how it is different, independent as to how this would be handled in our source tree. For example: if they both use the same processor and instruction set and have the same runtime specification, you can say that they are both MIPS. The endianness is just a slight variation of the general theme. Thus (in this case), ARCH=mips and MACH=algor or MACH=sgimips... We have something like this for ia64. The processor can operate in BE and LE and emulates i386. Nonetheless, it's still the ia64 architecture. Hence, MACHINE_ARCH is ia64. Currently there are only 2 implementations of the processor and we don't care, but more are on their way. The architecture allows that. I would expect us to use the machine keyword in the kernel config file if we cannot capture all variations at the same time and are forced to make different machine targets. So, given that we have MACHINE_ARCH and MACHINE already to our disposal, I don't get the feeling that we are in need to add something else because the problem space appears 2D, not 3D. Right? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] But that determines what machine is a link to, and files.machine that is read. So that means that we need to have machine/*.h stubbed in both algor/ and sgimips/. Each of those defines the things they need to be defined, and then includes mips/\.h. Even if we know that we never need to have any changes, or otherwise have the abstraction the wrong way around. It also means that you have to pull in the mips options and files list for both of those ports, and so on. So you end up having machine $(MACHINE) and having to explicitly inherit bit by bit everything that you may need into the meta-port (algor or sgimips -- $(MACHINE)), in an explicit manner. My way, machine is mips and the headers which provide tunables include platform/\.h. Optional hardware for a given platform is pulled in via files.mips optional directives. Everything is less convoluted, IMHO. No implementation details please. I did my best, but I still have to show that there are two explicit meta-ports. My previous email had no implementation details, just general structure, and you rejected it, so I hope this is better. It's different :-) What I'm trying to get at is how sgimips is the same as algor and likewise how it is different, independent as to how this would be handled in our source tree. For example: if they both use the same processor and instruction set and have the same runtime specification, you can say that they are both MIPS. The endianness is just a slight variation of the general theme. Thus (in this case), ARCH=mips and MACH=algor or MACH=sgimips... That's what I'm saying, yes. So, given that we have MACHINE_ARCH and MACHINE already to our disposal, I don't get the feeling that we are in need to add something else because the problem space appears 2D, not 3D. Right? That's what I'm trying to do, in a clean way. See my short version message, if you like. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
Benno Rice [EMAIL PROTECTED] writes: On Wed, 2003-01-29 at 11:18, Juli Mallett wrote: * De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] In short, platform provides machinery for a single port of FreeBSD which represents exactly one MACHINE_ARCH to support a numbe of different hardware platforms - MACHINE - under a unified system, without interfering with how anything works, and without doing it in a convoluted/imho-backwards way. There is not a way to mix MACHINE and MACHINE_ARCH within a single port, as it is now. You have to duplicate things like pc98 does. I'd also like to point out that PowerPC will benefit greatly from this. PowerPC platforms vary wildly in how they do various things (incl. endianness in some cases) and so this provides a much cleaner mechanism to select a set of platform quirks than trying to do what i386/pc98 do. Perhaps if we could see PC98 converted to this design the advantages would become obvious. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 04:49:55PM -0800, Juli Mallett wrote: So, given that we have MACHINE_ARCH and MACHINE already to our disposal, I don't get the feeling that we are in need to add something else because the problem space appears 2D, not 3D. Right? That's what I'm trying to do, in a clean way. See my short version message, if you like. Ok. Now that we've established that the platform keyword is not needed, is there any meaning we attach to MACHINE that conflicts with the meaning it must have in order to solve the mips/powerpc problem? Or do we not attach a certain meaning to MACHINE that we should attach to it? For example: When building world, we can test for MACHINE_ARCH and MACHINE. Do you need to select a (default) compiler target based on MACHINE or not? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Tue, Jan 28, 2003 at 04:49:55PM -0800, Juli Mallett wrote: So, given that we have MACHINE_ARCH and MACHINE already to our disposal, I don't get the feeling that we are in need to add something else because the problem space appears 2D, not 3D. Right? That's what I'm trying to do, in a clean way. See my short version message, if you like. Ok. Now that we've established that the platform keyword is not needed, is there any meaning we attach to MACHINE that conflicts with the meaning it must have in order to solve the mips/powerpc problem? Or do we not attach a certain meaning to MACHINE that we should attach to it? No, we have not established that. Using machine still does not fix the machine issues. If we keep everything under mips for the mchine architecture (/sys/mips) then we need platform to get stuff from the per-$MACHINE directories in a generic way, or every $MACHINE needs to be known to the upper-level, exposing implementation details along the lines of every machine header (those are under MACHINE_ARCH _not_ MACHINE's domain, given how config works). If we keep all the meta- ports under /sys/mips then machine is /sys/mips/include, NOT e.g. /sys/mips/sgimips or /sys/mips/sgimips/include with a machine sgimips and neither is an option set to turn on optional SGIMIPS hardware. The machine keyword has NOTHING to do with the machine directory, except in the case where /sys/$MACHINE/compile/$KERNCONF is where the port ends up being built, and where the machine setting is equal to $MACHINE above. Such as pc98. I'm not talking about how pc98 works, with platform. That way is dumb and braindead and does not work. As Benno said, platform is for per-platform quirks. We attach lots of meaning to MACHINE. You keep missing that that is NOT the same as the machine keyword. It is, however, the same as the platform keyword. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 05:42:59PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Tue, Jan 28, 2003 at 04:49:55PM -0800, Juli Mallett wrote: So, given that we have MACHINE_ARCH and MACHINE already to our disposal, I don't get the feeling that we are in need to add something else because the problem space appears 2D, not 3D. Right? That's what I'm trying to do, in a clean way. See my short version message, if you like. Ok. Now that we've established that the platform keyword is not needed, is there any meaning we attach to MACHINE that conflicts with the meaning it must have in order to solve the mips/powerpc problem? Or do we not attach a certain meaning to MACHINE that we should attach to it? No, we have not established that. *sigh* Is the problem space 2D or 3D? We attach lots of meaning to MACHINE. You keep missing that that is NOT the same as the machine keyword. And you keep missing that I don't assume that it cannot be made the same. That's why I ask about meaning and that's why I want things to be discussed on an abstract level. It is, however, the same as the platform keyword. You also fail to see that the consequence of adding platform is beyond the mere recognition of the keyword. Only when the problem space is 3D, do you need to add a new entity for sure. If the problem space is 2D, you may be able to solve it with the existing knobs. Yes, this may mean that you may have to stop using it for whatever purpose (right or wrong) it's used now. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] No, we have not established that. *sigh* Is the problem space 2D or 3D? Define your terms better. I could argue the number of axes very easily, and you could come back and argue against them. We attach lots of meaning to MACHINE. You keep missing that that is NOT the same as the machine keyword. And you keep missing that I don't assume that it cannot be made the same. That's why I ask about meaning and that's why I want things to be discussed on an abstract level. OK. Well, if you make them the same, you are hacking up an existing thing to mean something vastly different, which IMO is ugly and full of repetition, and wholly un-flesible. Unless you propose to create platform based on MACHINE in the MACHINE_ARCH != MACHINE case anyway, and use that, there is now even more duplication and obfuscation that must be done to e.g. the headers. It is, however, the same as the platform keyword. You also fail to see that the consequence of adding platform is beyond the mere recognition of the keyword. Only when the problem space is 3D, do you need to add a new entity for sure. If the problem space is 2D, you may be able to solve it with the existing knobs. Yes, this may mean that you may have to stop using it for whatever purpose (right or wrong) it's used now. I don't want to change the meaning of machine, the two things are orthogonal, but because the name is similar you want to callesce them. I want to add a new paradigm of FreeBSD ports, as well as the mechanism to do this, based on what I want to do, and the fact that it makes sense to Benno. We're just providing a set of quirks, and that should be something that fits in nicely as an addition. And it does, and it stays out of the way of things that do not need it, and provides IMO the cleanest design. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 06:20:13PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] No, we have not established that. *sigh* Is the problem space 2D or 3D? Define your terms better. I could argue the number of axes very easily, and you could come back and argue against them. So far you have defined the problem as a 2D problem and I have not argued with that. You're getting extremely incomprehensible... We attach lots of meaning to MACHINE. You keep missing that that is NOT the same as the machine keyword. And you keep missing that I don't assume that it cannot be made the same. That's why I ask about meaning and that's why I want things to be discussed on an abstract level. OK. Well, if you make them the same, you are hacking up an existing thing to mean something vastly different, which IMO is ugly and full of repetition, and wholly un-flesible. Ok, if making them the same means that we're changing the meaning of machine, then clearly you know what the meaning is now. Please tell me. Unless you propose to create platform based on MACHINE in the MACHINE_ARCH != MACHINE case anyway, and use that, there is now even more duplication and obfuscation that must be done to e.g. the headers. I did not propose anything yet. I'm trying to understand what it is you're talking about. At the same time I'm trying to avoid defining the problem in terms of the proposed solution so that I can validate that there is a problem, whether the solution you proposes addresses that problem and see if other solutions exist that solve the problem so that we can find the best alternative. It is, however, the same as the platform keyword. You also fail to see that the consequence of adding platform is beyond the mere recognition of the keyword. Only when the problem space is 3D, do you need to add a new entity for sure. If the problem space is 2D, you may be able to solve it with the existing knobs. Yes, this may mean that you may have to stop using it for whatever purpose (right or wrong) it's used now. I don't want to change the meaning of machine, the two things are orthogonal, but because the name is similar you want to callesce them. Again: what does machine mean to you. To what is it othogonal and with what do you think I want to coalesce it that has a similar name? I want to add a new paradigm of FreeBSD ports, as well as the mechanism to do this, based on what I want to do, and the fact that it makes sense to Benno. Good. What is the new paradigm? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] We attach lots of meaning to MACHINE. You keep missing that that is NOT the same as the machine keyword. And you keep missing that I don't assume that it cannot be made the same. That's why I ask about meaning and that's why I want things to be discussed on an abstract level. OK. Well, if you make them the same, you are hacking up an existing thing to mean something vastly different, which IMO is ugly and full of repetition, and wholly un-flesible. Ok, if making them the same means that we're changing the meaning of machine, then clearly you know what the meaning is now. Please tell me. Right now, it says where to get files, options, and Makefile. In the paradigm I chose to use, these are all part of the master port, rather than the meta-port. Each machine is actually closer to MACHINE_ARCH in intended meaning from config(8), as it is intended to be related to the cpu directive, e.g. machine defines the architecture, say, mips, and to go with it, you define a specific CPU, e.g. R4400. Unless you propose to create platform based on MACHINE in the MACHINE_ARCH != MACHINE case anyway, and use that, there is now even more duplication and obfuscation that must be done to e.g. the headers. I did not propose anything yet. I'm trying to understand what it is you're talking about. At the same time I'm trying to avoid defining the problem in terms of the proposed solution so that I can validate that there is a problem, whether the solution you proposes addresses that problem and see if other solutions exist that solve the problem so that we can find the best alternative. Okay, but understand I'm doing it this way as opposed to using the existing mechanism as a kludge, as that is roughly what NetBSD does, and other systems, and also similar to how we do pc98, and while that is vaguely meaningful, it ends up being messy like pc98, or like the system NetBSD has. I want to shift to a different paradigm, as discussed, and see below. It is, however, the same as the platform keyword. You also fail to see that the consequence of adding platform is beyond the mere recognition of the keyword. Only when the problem space is 3D, do you need to add a new entity for sure. If the problem space is 2D, you may be able to solve it with the existing knobs. Yes, this may mean that you may have to stop using it for whatever purpose (right or wrong) it's used now. I don't want to change the meaning of machine, the two things are orthogonal, but because the name is similar you want to callesce them. Again: what does machine mean to you. To what is it othogonal and with what do you think I want to coalesce it that has a similar name? It provides something orthogonal to what platform does, and I want it to stay that way, so that things fit below. I want to add a new paradigm of FreeBSD ports, as well as the mechanism to do this, based on what I want to do, and the fact that it makes sense to Benno. Good. What is the new paradigm? As explained, you have a master port, to the architecture, assume that it is mips ok? That's /sys/mips on FreeBSD. Each architecture port may have a number of specific platforms it supports. These map to the definitions of MACHINE_ARCH and MACHINE respectively. An architecture port then pulls in, based off the platform directive, appropriate options to have MACHINE-specific code. If we assume that is sgimips then it is headers and code in /sys/mips/sgimips. Based on the option defined in options.mips and files.mips. The build glue sees that our MACHINE_ARCH directory contains a MACHINE equivalent directory, and it sets up the platform directory, the meta-port headers, which is then used by the architecture port to tune the meta-data of the port. Like Benno put it (probably better than I did) you have an architecture, and you have MACHINE-specific quirks. Those define a platform. And a platform is meta-port data to the architecture. I feel very good about that definition, does that work for you? Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Mike Barcroft [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] Benno Rice [EMAIL PROTECTED] writes: On Wed, 2003-01-29 at 11:18, Juli Mallett wrote: * De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] In short, platform provides machinery for a single port of FreeBSD which represents exactly one MACHINE_ARCH to support a numbe of different hardware platforms - MACHINE - under a unified system, without interfering with how anything works, and without doing it in a convoluted/imho-backwards way. There is not a way to mix MACHINE and MACHINE_ARCH within a single port, as it is now. You have to duplicate things like pc98 does. I'd also like to point out that PowerPC will benefit greatly from this. PowerPC platforms vary wildly in how they do various things (incl. endianness in some cases) and so this provides a much cleaner mechanism to select a set of platform quirks than trying to do what i386/pc98 do. Perhaps if we could see PC98 converted to this design the advantages would become obvious. That would be an interesting idea, but I don't know if the pc98 people feel like it. One of them voiced dislike for having lots of #ifdef code, as you may have seen, so I don't know. Unless we can convince them that that is cleaner and that pc98 is not a first-class port itself, which I doubt is very likely. Note that when I say first-class, I mean wholly unique architecture which should define everything, e.g. sparc64 or alpha. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
Mike Barcroft wrote: Benno Rice [EMAIL PROTECTED] writes: I'd also like to point out that PowerPC will benefit greatly from this. PowerPC platforms vary wildly in how they do various things (incl. endianness in some cases) and so this provides a much cleaner mechanism to select a set of platform quirks than trying to do what i386/pc98 do. Perhaps if we could see PC98 converted to this design the advantages would become obvious. That's quite the likeable idea. The alternative is that we end up with mixed legacy code and new code, as people don't care about bringing the PC98 up to date so long as it still works. It's always better to have one true way to do things: it makes it easier to document. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 07:01:58PM -0800, Juli Mallett wrote: * De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] We attach lots of meaning to MACHINE. You keep missing that that is NOT the same as the machine keyword. And you keep missing that I don't assume that it cannot be made the same. That's why I ask about meaning and that's why I want things to be discussed on an abstract level. OK. Well, if you make them the same, you are hacking up an existing thing to mean something vastly different, which IMO is ugly and full of repetition, and wholly un-flesible. Ok, if making them the same means that we're changing the meaning of machine, then clearly you know what the meaning is now. Please tell me. Right now, it says where to get files, options, and Makefile. But is that the meaning or just the implementation? For pc98, machine is set to pc98 and what we build is a system that has MACHINE_ARCH=i386 and MACHINE=pc98. Right? For i386, machine is set to i386 and what we build is a system that has MACHINE_ARCH=i386 and MACHINE=i386. Right? Thus: machine identifies a variant for a particular architecture, right? The implementation is messy and I can understand that you don't want to do it the same way. See below. In the paradigm I chose to use, these are all part of the master port, rather than the meta-port. Each machine is actually closer to MACHINE_ARCH in intended meaning from config(8), as it is intended to be related to the cpu directive, e.g. machine defines the architecture, say, mips, and to go with it, you define a specific CPU, e.g. R4400. But isn't this is a change in meaning of machine? Put differently, aren't we forced to change the value for machine for pc98 if we want it to work with your paradigm? I did not propose anything yet. I'm trying to understand what it is you're talking about. At the same time I'm trying to avoid defining the problem in terms of the proposed solution so that I can validate that there is a problem, whether the solution you proposes addresses that problem and see if other solutions exist that solve the problem so that we can find the best alternative. Okay, but understand I'm doing it this way as opposed to using the existing mechanism as a kludge, as that is roughly what NetBSD does, and other systems, and also similar to how we do pc98, and while that is vaguely meaningful, it ends up being messy like pc98, or like the system NetBSD has. I want to shift to a different paradigm, as discussed, and see below. NetBSD has MACHINE_ARCH=mipsel and MACHINE_ARCH=mipseb. They choose to make them different architectures. I understand you are not going to do that, right? Good. What is the new paradigm? As explained, you have a master port, to the architecture, assume that it is mips ok? That's /sys/mips on FreeBSD. Each architecture port may have a number of specific platforms it supports. These map to the definitions of MACHINE_ARCH and MACHINE respectively. An architecture port then pulls in, based off the platform directive, appropriate options to have MACHINE-specific code. If we assume that is sgimips then it is headers and code in /sys/mips/sgimips. Based on the option defined in options.mips and files.mips. The build glue sees that our MACHINE_ARCH directory contains a MACHINE equivalent directory, and it sets up the platform directory, the meta-port headers, which is then used by the architecture port to tune the meta-data of the port. Like Benno put it (probably better than I did) you have an architecture, and you have MACHINE-specific quirks. Those define a platform. And a platform is meta-port data to the architecture. I feel very good about that definition, does that work for you? Yes. It's what I've been saying all along, except that I use existing variables/keywords and you don't :-) I used MACHINE_ARCH to hold the identification of the master port (mips in this case) and used MACHINE to hold the identification of the platform/implementation (sgimips in this example). So do you, except you map platform onto MACHINE, whereas I map machine onto MACHINE. Now, where I think this went wrong is that you linked this to how it is done with pc98 and how config has it implemented and that is what you don't want. You want a better (directory) structure. My explicit request to not talk in terms of implementation, but instead to keep it abstract failed to prevent that. To be perfectly clear: I think your directory structure makes sense and is better than what we do for pc98. This has on an abstract level nothing toi do with the keyword we use in config. Are we in sync? If we are in sync, we can discuss the ups and down and see what we think works best. Clearly, if we make machine equivalent to MACHINE and we want to have a directory structure as you describe, things need
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] Good. What is the new paradigm? As explained, you have a master port, to the architecture, assume that it is mips ok? That's /sys/mips on FreeBSD. Each architecture port may have a number of specific platforms it supports. These map to the definitions of MACHINE_ARCH and MACHINE respectively. An architecture port then pulls in, based off the platform directive, appropriate options to have MACHINE-specific code. If we assume that is sgimips then it is headers and code in /sys/mips/sgimips. Based on the option defined in options.mips and files.mips. The build glue sees that our MACHINE_ARCH directory contains a MACHINE equivalent directory, and it sets up the platform directory, the meta-port headers, which is then used by the architecture port to tune the meta-data of the port. Like Benno put it (probably better than I did) you have an architecture, and you have MACHINE-specific quirks. Those define a platform. And a platform is meta-port data to the architecture. I feel very good about that definition, does that work for you? Yes. It's what I've been saying all along, except that I use existing variables/keywords and you don't :-) I used MACHINE_ARCH to hold the identification of the master port (mips in this case) and used MACHINE to hold the identification of the platform/implementation (sgimips in this example). So do you, except you map platform onto MACHINE, whereas I map machine onto MACHINE. Now, where I think this went wrong is that you linked this to how it is done with pc98 and how config has it implemented and that is what you don't want. You want a better (directory) structure. My explicit request to not talk in terms of implementation, but instead to keep it abstract failed to prevent that. To be perfectly clear: I think your directory structure makes sense and is better than what we do for pc98. This has on an abstract level nothing toi do with the keyword we use in config. Are we in sync? If we are in sync, we can discuss the ups and down and see what we think works best. Clearly, if we make machine equivalent to MACHINE and we want to have a directory structure as you describe, things need to change. Do we want that, is it doable. One thing is for sure: we don't need both machine and platform in a single kernel config file to do what we want. But is what we want doable with just machine? Yes, you are following me. But also, you mention that machine as implemented means what I said it means, but there is other precident for using it as I say. For example, BSD/OS uses machine sparc and options SUN4M. NetBSD uses machine in a way more similar to what you want, but like machine sgimips mips for example. What we want... Could be done with machine, if we allow there to be no files.XXX for a given machine XXX and so on, but I think this is less clear. How would you propose to write the following: %%% machine mips platformsgimips %%% Would you write it as: %%% machine mips sgimips %%% If so, how do you know which is MACHINE and which is MACHINE_ARCH? How do you accurately get a platform include directory? Certainly we don't want to make i386 do this: %%% architecturei386 machine i386 %%% Because that would be backwards... But an addition of something like platform would allow it to be orthogonal to existing structure, it would not mandate its use, of course... And so on. There's more at stake than just what we need, it also has to make sense when we don't need it, and so on. The above two things I have suggested break in dumb ways... If you just figure out the MACHINE_ARCH based on /sys/XXX/conf's XXX bit, then you could define MACHINE based on the machine directive, and as such, on i386 and sparc64 and ... it would do the right thing, and it would allow the MIPS stuff to be done, but it breaks the existing pc98 stuff, because it resides in /sys/$MACHINE. I really think we need platform, and I really think it needs to come in as part of new infrastructure, as it provides something totally new which breaks in interesting ways if you don't make it optional and cleanly seperated as I've tried to do. Again, this is based off experience with a number of build systems, and the needs of PowerPC and MIPS, and also is something I run on my laptop, which is i386. It stays out of the way and only affects those explicit consumers of it. The more we discuss making machine act like platform, the more concerns that come to my head for that, and the more platform seems right to me. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 08:57:38PM -0800, Juli Mallett wrote:
Yes, you are following me. But also, you mention that machine
as implemented means what I said it means, but there is other
precident for using it as I say. For example, BSD/OS uses
machine sparc and options SUN4M. NetBSD uses machine in a
way more similar to what you want, but like machine sgimips mips
for example. What we want... Could be done with machine, if we
allow there to be no files.XXX for a given machine XXX and so
on, but I think this is less clear. How would you propose to write
the following:
%%%
machine mips
platform sgimips
%%%
Would you write it as:
%%%
machine mips sgimips
%%%
No, I see MACHINE_ARCH implied by where you run config. This seems
strange and I'm not completely sure it's a good thing, but
MACHINE_ARCH is defined in /sys/${ARCH}/include/param.h and
defining the architecture in the kernel config file only allows
a limited freedom; namely the freedom to have the config file
outside the source tree. It basicly only defines a directory,
nothing else. See also below for pc98.
Thus, MACHINE_ARCH is not specified and machine holds the
implementation (ie platform). This is exactly what we have
now, so you don't change the meaning.
There's more at stake than just what we need, it also has to make
sense when we don't need it, and so on. The above two things I
have suggested break in dumb ways... If you just figure out the
MACHINE_ARCH based on /sys/XXX/conf's XXX bit, then you could
define MACHINE based on the machine directive, and as such, on
i386 and sparc64 and ... it would do the right thing, and it
would allow the MIPS stuff to be done, but it breaks the existing
pc98 stuff, because it resides in /sys/$MACHINE.
Correct. I either want pc98 transformed or if that's not possible
or feasible, a keyword root, tree, directory or
nonstandardlocation to tell config(8) that the (sub-)port is
not where we normally have it. We then create a new keyword,
but it explcitly means a location, a path. The introduction of
platform is more confusing. First of all it maps to MACHINE,
while we have the machine keyword mapping to something else.
This is illogical. The machine keyword basicly controls
source layout and has nothing to do with the machine you're
building for. Again, illogical.
So, I'm not opposed to having a new variable if it's too hard to
do it without, but I think there's a more logical/optimal scheme
of naming and attaching meaning that does not affect the common
case (it only affects pc98).
affects those explicit consumers of it. The more we discuss
making machine act like platform, the more concerns that come
to my head for that, and the more platform seems right to me.
Ok, what are those exactly.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ]
[ Subjecte: Re: Patch to teach config(8) about platforms. ]
On Tue, Jan 28, 2003 at 08:57:38PM -0800, Juli Mallett wrote:
Yes, you are following me. But also, you mention that machine
as implemented means what I said it means, but there is other
precident for using it as I say. For example, BSD/OS uses
machine sparc and options SUN4M. NetBSD uses machine in a
way more similar to what you want, but like machine sgimips mips
for example. What we want... Could be done with machine, if we
allow there to be no files.XXX for a given machine XXX and so
on, but I think this is less clear. How would you propose to write
the following:
%%%
machine mips
platformsgimips
%%%
Would you write it as:
%%%
machine mips sgimips
%%%
No, I see MACHINE_ARCH implied by where you run config. This seems
strange and I'm not completely sure it's a good thing, but
MACHINE_ARCH is defined in /sys/${ARCH}/include/param.h and
defining the architecture in the kernel config file only allows
a limited freedom; namely the freedom to have the config file
outside the source tree. It basicly only defines a directory,
nothing else. See also below for pc98.
Thus, MACHINE_ARCH is not specified and machine holds the
implementation (ie platform). This is exactly what we have
now, so you don't change the meaning.
I'm not talking only about MACHINE_ARCH, but also where the MD files
and so on are. If we moved to sys/ARCH/conf/files and so on, I'd
be more supportive of such an approach. And if we made pc98 not
dumb in this regard (with consent of their maintainers).
There's more at stake than just what we need, it also has to make
sense when we don't need it, and so on. The above two things I
have suggested break in dumb ways... If you just figure out the
MACHINE_ARCH based on /sys/XXX/conf's XXX bit, then you could
define MACHINE based on the machine directive, and as such, on
i386 and sparc64 and ... it would do the right thing, and it
would allow the MIPS stuff to be done, but it breaks the existing
pc98 stuff, because it resides in /sys/$MACHINE.
Correct. I either want pc98 transformed or if that's not possible
or feasible, a keyword root, tree, directory or
nonstandardlocation to tell config(8) that the (sub-)port is
not where we normally have it. We then create a new keyword,
That sort of keyword is even more convoluted than platform.
but it explcitly means a location, a path. The introduction of
platform is more confusing. First of all it maps to MACHINE,
while we have the machine keyword mapping to something else.
MACHINE is a cpp define and (relatedly) is defined by make(1),
it isn't a config file element. Why do they have to be related
just because they by coincidence have the same name?
This is illogical. The machine keyword basicly controls
source layout and has nothing to do with the machine you're
building for. Again, illogical.
Yes it does, in a traditional meaning of machine. This is being
built for the MIPS machine, with support for the sgimips platform.
Or This is being built for the VAX [machine].
So, I'm not opposed to having a new variable if it's too hard to
do it without, but I think there's a more logical/optimal scheme
of naming and attaching meaning that does not affect the common
case (it only affects pc98).
My case affects nothing, therefore, since yours is good for only
affecting one, mine is better for only affecting none, and for working
right in every case. You don't like my choice of how, that's fine,
you don't have to maintain a port which uses it. All the more reason
for it to not be one that is even used by you at all.
I've made a note that you don't think my way is optimal. I do, and
that's that, at this point. No black magic, no convoluted config
files, etc. Go deal with the ODE config and Mach's configuration
files, I have. Or NetBSD's. Or OpenBSD's. At this point, I am
convinced that the platform keyword is the least offensive and most
productive way of doing all of this, and so on, being someone who
has worked with more backwards methods, and being the person who
had to deal with this first, and came up with something that suits
the two groups who need it most (the pc98 mistake is probably near
impossible to correct, due to the historical nature), MIPS, and
PowerPC.
If you can convince the PowerPC folks to go with what you suggest,
then I'll be glad to also push for files, etc., to be in the proper
place, as the significance of the configuration file's contents
becoems even less important (except for the option of having a
directive point to the meta-port, which is horrid, and which I'd
really dislike seeing go in as a solution to part of these issues).
Or I suppose, since you seem to have more of a desire to re-spend
the time I spent planning this out, you could take it up with the
technical
Re: Patch to teach config(8) about platforms.
On Wed, 2003-01-29 at 16:18, Marcel Moolenaar wrote:
On Tue, Jan 28, 2003 at 08:57:38PM -0800, Juli Mallett wrote:
Yes, you are following me. But also, you mention that machine
as implemented means what I said it means, but there is other
precident for using it as I say. For example, BSD/OS uses
machine sparc and options SUN4M. NetBSD uses machine in a
way more similar to what you want, but like machine sgimips mips
for example. What we want... Could be done with machine, if we
allow there to be no files.XXX for a given machine XXX and so
on, but I think this is less clear. How would you propose to write
the following:
%%%
machine mips
platformsgimips
%%%
Would you write it as:
%%%
machine mips sgimips
%%%
No, I see MACHINE_ARCH implied by where you run config. This seems
strange and I'm not completely sure it's a good thing, but
MACHINE_ARCH is defined in /sys/${ARCH}/include/param.h and
defining the architecture in the kernel config file only allows
a limited freedom; namely the freedom to have the config file
outside the source tree. It basicly only defines a directory,
nothing else. See also below for pc98.
Thus, MACHINE_ARCH is not specified and machine holds the
implementation (ie platform). This is exactly what we have
now, so you don't change the meaning.
This is just confusing. Having just played with this, if I specify
machine i386 while in the sys/powerpc/conf directory, I end up with an
unbuildable configuration as it sucks in the i386 Makefile but assumes
that it's arch-specific files are in ../../include.
This means that we would need to use:
machine powermac
in the config file while being in the powerpc directory, and then have a
sys/conf/*.powermac (along with all the other ones). This to me is
backwards.
If we follow Juli's suggestion, we have:
machine powerpc
platformpowermac
and this uses the standard sys/conf/*.powerpc and simply pick up a set
of platform-dependant includes from sys/powerpc/powermac. The options
logic handles the rest as we already have lines in
sys/conf/files.powerpc like:
powerpc/powermac/uninorth.c optionalpowermac pci
powerpc/powermac/macio.coptionalpowermac pci
powerpc/powermac/ata_macio.coptionalpowermac ata
Then when we head off to implement a little-endian powerpc platform we
can use:
machine powerpc
platformlittle-endian-platform
and it'll grab it's includes out of sys/powerpc/little-endian-platform
and we can do the same sort of files.powerpc magic as above.
Juli's form is also more explicit, which I find appealing.
There's more at stake than just what we need, it also has to make
sense when we don't need it, and so on. The above two things I
have suggested break in dumb ways... If you just figure out the
MACHINE_ARCH based on /sys/XXX/conf's XXX bit, then you could
define MACHINE based on the machine directive, and as such, on
i386 and sparc64 and ... it would do the right thing, and it
would allow the MIPS stuff to be done, but it breaks the existing
pc98 stuff, because it resides in /sys/$MACHINE.
Correct. I either want pc98 transformed or if that's not possible
or feasible, a keyword root, tree, directory or
nonstandardlocation to tell config(8) that the (sub-)port is
not where we normally have it. We then create a new keyword,
but it explcitly means a location, a path. The introduction of
platform is more confusing. First of all it maps to MACHINE,
while we have the machine keyword mapping to something else.
This is illogical. The machine keyword basicly controls
source layout and has nothing to do with the machine you're
building for. Again, illogical.
So, I'm not opposed to having a new variable if it's too hard to
do it without, but I think there's a more logical/optimal scheme
of naming and attaching meaning that does not affect the common
case (it only affects pc98).
Juli's patches don't touch the common case. If you don't specify a
platform then you don't get that extra logic. Easy. I agree that
moving pc98 over to whatever system we want to use is a good idea, but
for the moment I'd be happy with not forcing mips and powerpc down the
same road as pc98 which I see as being overly painful and confusing.
--
Benno Rice [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 09:37:16PM -0800, Juli Mallett wrote: but it explcitly means a location, a path. The introduction of platform is more confusing. First of all it maps to MACHINE, while we have the machine keyword mapping to something else. MACHINE is a cpp define and (relatedly) is defined by make(1), it isn't a config file element. Why do they have to be related just because they by coincidence have the same name? No, because using machine in your proposal would then be more like what MACHINE_ARCH means everywhere else. There already is confusion about the difference between MACHINE and MACHINE_ARCH and you're only adding to that confusion by using machine in the same way MACHINE_ARCH is used everywhere else. You don't like my choice of how, that's fine, you don't have to maintain a port which uses it. All the more reason for it to not be one that is even used by you at all. Blablabla. Your proposal affects FreeBSD. I'm having a constructive discussion about your proposal because I like to understand your point of view and tell you mine. Childish behaviour does not impress me. In fact it only tells me that you're incapable of convincing me and that you're incapable of looking at it from my point of view and tell me where I'm missing something. No, you're fixated and it took a lot of effort from my end to get to a point where we understood each other. If you're tired of it, try an open mind next time. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Tue, Jan 28, 2003 at 09:37:16PM -0800, Juli Mallett wrote: but it explcitly means a location, a path. The introduction of platform is more confusing. First of all it maps to MACHINE, while we have the machine keyword mapping to something else. MACHINE is a cpp define and (relatedly) is defined by make(1), it isn't a config file element. Why do they have to be related just because they by coincidence have the same name? No, because using machine in your proposal would then be more like what MACHINE_ARCH means everywhere else. There already is confusion about the difference between MACHINE and MACHINE_ARCH and you're only adding to that confusion by using machine in the same way MACHINE_ARCH is used everywhere else. And by using machine in the same way it is used everywhere else. You don't like my choice of how, that's fine, you don't have to maintain a port which uses it. All the more reason for it to not be one that is even used by you at all. Blablabla. Your proposal affects FreeBSD. I'm having a constructive discussion about your proposal because I like to understand your point of view and tell you mine. Childish behaviour does not impress me. In fact it only tells me that you're incapable of convincing me and that you're incapable of looking at it from my point of view and tell me where I'm missing something. No, you're fixated and it took a lot of effort from my end to get to a point where we understood each other. If you're tired of it, try an open mind next time. No Marcel, I've been through your discussion already, with myself, when I first did this. I came up with the optimal way of doing it in my head, and considered all the possibilities. I also have to use it. What I was saying is that I have the need for it, and so I have had to deal with the implementation details. I've compared to every config utility I've worked with, and I've worked with the build systems of * that uses a similar mechanism, that I can get my hands on, and I prefer my way. I don't have the energy to go nowhere with you for a long time. I already went nowhere with me for a long time. I looked at it from your point of view months ago, and to make sure I didn't miss something, I looked at it from your point of view today, even made the necessary changes to the config(8) program to do it that way again, and tested it and so on. I did everything but draw out a map on a whiteboard (again). I used a piece of paper. Sorry if you find it childish to want to move on from that sort of rehashing. Not my intention, and I had no problem with our discussion. Only when I realised that you kept coming back to things I'd already been through, and I began to feel a bit over whelmed by the nature of the conversation, which was leaning towards bikeshedding, did I try to back out of it. I didn't go and give up when you were rehashing all this. When I gave up, I advised you to use your energy to come up with a working solution for this, and make it suit all the people who need it and will be affected by it, as I did. I don't doubt you could come up with something better over time, but I don't see why? If you happen to have something much, much better, please just get people to agree to it. As I have said, I already satisfied those affected (those who want to be affected), and I'm apparently not the only one who has an explicit preference of one way to the other (see what Benno has posted)... This isn't a matter of who's more childish or something, it's code, it's getting the job done, and making it possible to do the right thing. I'm sorry if that was how it seemed... And yes, I am incapable of convincing you, for now. Maybe if you spent the time on this problem I did, I could, or maybe if you had to deal with it, I could. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Wed, Jan 29, 2003 at 04:56:10PM +1100, Benno Rice wrote:
No, I see MACHINE_ARCH implied by where you run config. This seems
strange and I'm not completely sure it's a good thing, but
MACHINE_ARCH is defined in /sys/${ARCH}/include/param.h and
defining the architecture in the kernel config file only allows
a limited freedom; namely the freedom to have the config file
outside the source tree. It basicly only defines a directory,
nothing else. See also below for pc98.
Thus, MACHINE_ARCH is not specified and machine holds the
implementation (ie platform). This is exactly what we have
now, so you don't change the meaning.
This is just confusing. Having just played with this, if I specify
machine i386 while in the sys/powerpc/conf directory, I end up with an
unbuildable configuration as it sucks in the i386 Makefile but assumes
that it's arch-specific files are in ../../include.
Yes. We now have config(8) interpret machine in such a way that
it works for pc98 and therefore does not work right iwith what we
like to achieve. That needs to change for it to work.
Juli's form is also more explicit, which I find appealing.
Agreed. There's an advantage there, but see also my reply to
Juli about the use of machine to mean MACHINE_ARCH and the
use of platform to mean MACHINE. This I don't find appealing.
Juli's patches don't touch the common case.
We have 3 architectures that have multiple machines or platforms
(mips, powerpc and i386). Setting platform for mips and powerpc
and not i386 means that you're setting it for the common case,
because you could have nonstandardlocation defined for only pc98.
Again, this is just looking at it from a different point of view,
but a point of view we all have in a year from now when we moved
there.
platform then you don't get that extra logic. Easy. I agree that
moving pc98 over to whatever system we want to use is a good idea, but
for the moment I'd be happy with not forcing mips and powerpc down the
same road as pc98 which I see as being overly painful and confusing.
Agreed. We should not do the same, but instead of saying that we
do mips and powerpc different, I think we should say that mips and
powerpc do it the normal way and pc98 does it differently. I like
to use an extra keyword for the weird case (pc98) and not the normal
(common) case. See also above, this is looking at it from a point
of view we'll going to have in the future, not a point of view
we all have now.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Wed, 2003-01-29 at 17:25, Marcel Moolenaar wrote:
On Wed, Jan 29, 2003 at 04:56:10PM +1100, Benno Rice wrote:
No, I see MACHINE_ARCH implied by where you run config. This seems
strange and I'm not completely sure it's a good thing, but
MACHINE_ARCH is defined in /sys/${ARCH}/include/param.h and
defining the architecture in the kernel config file only allows
a limited freedom; namely the freedom to have the config file
outside the source tree. It basicly only defines a directory,
nothing else. See also below for pc98.
Thus, MACHINE_ARCH is not specified and machine holds the
implementation (ie platform). This is exactly what we have
now, so you don't change the meaning.
This is just confusing. Having just played with this, if I specify
machine i386 while in the sys/powerpc/conf directory, I end up with an
unbuildable configuration as it sucks in the i386 Makefile but assumes
that it's arch-specific files are in ../../include.
Yes. We now have config(8) interpret machine in such a way that
it works for pc98 and therefore does not work right iwith what we
like to achieve. That needs to change for it to work.
Agreed.
Juli's form is also more explicit, which I find appealing.
Agreed. There's an advantage there, but see also my reply to
Juli about the use of machine to mean MACHINE_ARCH and the
use of platform to mean MACHINE. This I don't find appealing.
I can see your point here, but if needed I'd rather see them renamed to
MACHINE (which maps to the current MACHINE_ARCH) and PLATFORM as MACHINE
and MACHINE_ARCH are confusingly similar.
Juli's patches don't touch the common case.
We have 3 architectures that have multiple machines or platforms
(mips, powerpc and i386). Setting platform for mips and powerpc
and not i386 means that you're setting it for the common case,
because you could have nonstandardlocation defined for only pc98.
Again, this is just looking at it from a different point of view,
but a point of view we all have in a year from now when we moved
there.
True. This is fixable though.
platform then you don't get that extra logic. Easy. I agree that
moving pc98 over to whatever system we want to use is a good idea, but
for the moment I'd be happy with not forcing mips and powerpc down the
same road as pc98 which I see as being overly painful and confusing.
Agreed. We should not do the same, but instead of saying that we
do mips and powerpc different, I think we should say that mips and
powerpc do it the normal way and pc98 does it differently. I like
to use an extra keyword for the weird case (pc98) and not the normal
(common) case. See also above, this is looking at it from a point
of view we'll going to have in the future, not a point of view
we all have now.
Ok, so are you saying here that Juli's patch is ok but we need to look
at how we deal with pc98?
Or are you saying that you would prefer to change how the machine
directive works in config(8) and introduce a new non-standard
directive for pc98?
If the former, I agree totally. If the latter, I'm not so sure. I'd
rather see the directive be platform as that is a much more accurate
name for it IMO. If this means we kill off the machine directive, then
that may be how it works.
--
Benno Rice [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 10:20:52PM -0800, Juli Mallett wrote: Your proposal affects FreeBSD. I'm having a constructive discussion about your proposal because I like to understand your point of view and tell you mine. Childish behaviour does not impress me. In fact it only tells me that you're incapable of convincing me and that you're incapable of looking at it from my point of view and tell me where I'm missing something. No, you're fixated and it took a lot of effort from my end to get to a point where we understood each other. If you're tired of it, try an open mind next time. No Marcel, I've been through your discussion already, with myself, when I first did this. Then my point of view must have triggered recognition. It didn't. I came up with the optimal way of doing it in my head, and considered all the possibilities. Great! Then you should have had no problem convincing me. I don't have the energy to go nowhere with you for a long time. That's not my fault. I already went nowhere with me for a long time. Yeah, my bad ;-) Sorry if you find it childish to want to move on from that sort of rehashing. No, I find it childish that you revert to childish arguments when you could have said that you've gone over this before already with multiple people and that this was intended as a formality only and that you didn't want to rehash it. In fact, you could just as well have committed this :-) I'm sorry if that was how it seemed... And yes, I am incapable of convincing you, for now. Maybe if you spent the time on this problem I did, I could, or maybe if you had to deal with it, I could. I have no problem accepting this. Maybe if I spend as much time on it as you apparently did I would have come to the same conclusion as you. It's possible that my point of view is the direct result of not having thought it through. The point is that I didn't spend the time and that I have in my head this notion that it makes sense in some other way. I think I did my best to get us in line in an attempt to find mutual understanding. I don't feel responsible for you perceiving it as bikeshedding. If it was, please tell me next time when I do it again. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] On Tue, Jan 28, 2003 at 10:20:52PM -0800, Juli Mallett wrote: Sorry if you find it childish to want to move on from that sort of rehashing. No, I find it childish that you revert to childish arguments when you could have said that you've gone over this before already with multiple people and that this was intended as a formality only and that you didn't want to rehash it. In fact, you could just as well have committed this :-) You're right. And I suppose it's just as well that everything is out there, and so on. Sorry it got a bit frustrating for both of us at times. I'm sorry if that was how it seemed... And yes, I am incapable of convincing you, for now. Maybe if you spent the time on this problem I did, I could, or maybe if you had to deal with it, I could. I have no problem accepting this. Maybe if I spend as much time on it as you apparently did I would have come to the same conclusion as you. It's possible that my point of view is the direct result of not having thought it through. The point is that I didn't spend the time and that I have in my head this notion that it makes sense in some other way. I think I did my best to get us in line in an attempt to find mutual understanding. I don't feel responsible for you perceiving it as bikeshedding. If it was, please tell me next time when I do it again. Thank you for trying harder to get it to the point of mutual understanding. That should have been my job, but I wasn't sure how to get you there. And you understand it your way, and maybe your understanding will lead to something better out of this, in the long run. And no, it wasn't really bikeshedding, it just began to feel that it was just a matter of but I think we should go at it from this angle when really all I intended to get was whether or not my code was OK. I fell short there, in what sort of review I wanted, or saught, or dealing with what I got. Thanx, juli. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Wed, Jan 29, 2003 at 05:32:51PM +1100, Benno Rice wrote:
Agreed. There's an advantage there, but see also my reply to
Juli about the use of machine to mean MACHINE_ARCH and the
use of platform to mean MACHINE. This I don't find appealing.
I can see your point here, but if needed I'd rather see them renamed to
MACHINE (which maps to the current MACHINE_ARCH) and PLATFORM as MACHINE
and MACHINE_ARCH are confusingly similar.
I'm not sure I understand you. I don't mind the capitalization,
just that we have MACHINE_ARCH and MACHINE defined on the hand
and machine and platform on the other. If you would ask a
person how they should be related, I can imagine that the
logical should would be to relate machine to MACHINE and
platform to MACHINE_ARCH. Which is opposite to what Juli
proposed. That's the unappealing part. Not a biggy, but
something that's better avoided now than fixed later.
Juli's patches don't touch the common case.
We have 3 architectures that have multiple machines or platforms
(mips, powerpc and i386). Setting platform for mips and powerpc
and not i386 means that you're setting it for the common case,
because you could have nonstandardlocation defined for only pc98.
Again, this is just looking at it from a different point of view,
but a point of view we all have in a year from now when we moved
there.
True. This is fixable though.
Yes. This would be enough to not worry about it now and I would
be fine with it.
Agreed. We should not do the same, but instead of saying that we
do mips and powerpc different, I think we should say that mips and
powerpc do it the normal way and pc98 does it differently. I like
to use an extra keyword for the weird case (pc98) and not the normal
(common) case. See also above, this is looking at it from a point
of view we'll going to have in the future, not a point of view
we all have now.
Ok, so are you saying here that Juli's patch is ok but we need to look
at how we deal with pc98?
I would not introduce a platform/foo.h, but rather
machine/${variant}/foo.h. The reason for this is that the
/usr/include/platform directory is only needed on powerpc and mips,
which seems to indicate that it should be under machine. Also,
the use of machine/${variant} allows us to install the headers for
all variants, which may improve cross-building. Note that I haven't
tried it on for size, so I'm not fixated on it. I was hoping this
would fall out of the discussion.
You see how the current approach affects other architectures if you
look at the diff for src/sys/conf/kmod.mk. All architectures,
including those that don't have multiple variants will have a link
added that mirrors the machine link. I find that aestheticly
displeasing. If you have the variants under machine, you don't
have to create more links.
The change to src/include/Makefile also seems to have a bug in
that it depends in /usr/include/platform to be created by
mtree, but I don't see and diff for that. Adding platform to
BSD.include.dist means that every architecture gets the
directory. Otherwise it has to be created by hand for those
platforms that have it.
The same happens in config(8) where we create a platform link
in all cases, not just for powerpc and mips.
Or are you saying that you would prefer to change how the machine
directive works in config(8) and introduce a new non-standard
directive for pc98?
That was the thought I was playing with.
If the former, I agree totally. If the latter, I'm not so sure. I'd
rather see the directive be platform as that is a much more accurate
name for it IMO. If this means we kill off the machine directive, then
that may be how it works.
I don't have a problem with the name platform, although I avoid it
for now to avoid confusion.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Tue, Jan 28, 2003 at 10:58:53PM -0800, Juli Mallett wrote: And no, it wasn't really bikeshedding, it just began to feel that it was just a matter of but I think we should go at it from this angle when really all I intended to get was whether or not my code was OK. I fell short there, in what sort of review I wanted, or saught, or dealing with what I got. I may have started wrong. Sorry. I fell in the middle of the thread and that may have resulted in us spiralling down on these nits without us getting to the points I had about the patch. I sent that in my reply to Benno. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
* De: Marcel Moolenaar [EMAIL PROTECTED] [ Data: 2003-01-28 ] [ Subjecte: Re: Patch to teach config(8) about platforms. ] You see how the current approach affects other architectures if you look at the diff for src/sys/conf/kmod.mk. All architectures, including those that don't have multiple variants will have a link added that mirrors the machine link. I find that aestheticly displeasing. If you have the variants under machine, you don't have to create more links. Only within the kernel build directory. That's at Peter's request. Doing it for the installed version breaks mkioctl. The change to src/include/Makefile also seems to have a bug in that it depends in /usr/include/platform to be created by mtree, but I don't see and diff for that. Adding platform to BSD.include.dist means that every architecture gets the directory. Otherwise it has to be created by hand for those platforms that have it. I forgot to make the BSD.include.dist change. D'oh. The same happens in config(8) where we create a platform link in all cases, not just for powerpc and mips. See the comment for kmod.mk. It doesn't affect anything. It can be changed, if you like. -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to teach config(8) about platforms.
On Sat, Jan 25, 2003 at 03:31:16PM -0800, Juli Mallett wrote: This patch is needed for the MIPS port's infrastructure, and will be needed for the PowerPC one, as given ports may support any number of platforms, on those architectures (and arguably, the same applies to i386 vs. pc98, but historically...). What it does is it sets up a build-time (and install-time, given right MACHINE_ARCH vs. MACHINE) platform include directory as an analogue to machine, where we need it. For kernels with a platform setting, it also sets the appropriate option for it. For example platform sgimips implies options SGIMIPS. Below are patches to makefile glue and config(8) itself. For clarity, this is used in cases where the platform may define its own values that a header needs, and as such, you might see something in machine/endian.h like: #include platform/endian.h I may not be fully following you, but I'd like to keep such changes down to what is absolutely necessary. Can you show your GENERIC sgimips config? Also show an example of where one would need a platform/endian.h on both powerpc (which is far enough along to discuss this need) and mips (which I think we should wait later until the port is officially in CVS). I have a guess, but I want to make absolutely sure. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Patch to teach config(8) about platforms.
This patch is needed for the MIPS port's infrastructure, and will be
needed for the PowerPC one, as given ports may support any number of
platforms, on those architectures (and arguably, the same applies to
i386 vs. pc98, but historically...). What it does is it sets up a
build-time (and install-time, given right MACHINE_ARCH vs. MACHINE)
platform include directory as an analogue to machine, where we
need it. For kernels with a platform setting, it also sets the
appropriate option for it. For example platform sgimips implies
options SGIMIPS. Below are patches to makefile glue and config(8)
itself.
For clarity, this is used in cases where the platform may define its
own values that a header needs, and as such, you might see something
in machine/endian.h like:
#include platform/endian.h
To let the platform determine the endianness, as the port may support
many such configurations with different values.
And note that while it is tempting to have platform be machine on
systems with MACHINE == MACHINE_ARCH, this breaks things like mkioctl.
%%%
diff -dur src/include/Makefile mips/include/Makefile
--- src/include/MakefileFri Jan 24 00:34:40 2003
+++ src/include/MakefileThu Jan 23 22:46:13 2003
@@ -80,7 +80,7 @@
.endfor
copies:
-.for i in ${LDIRS} ${LSYMSUBDIRS} machine crypto
+.for i in ${LDIRS} ${LSYMSUBDIRS} platform machine crypto
if [ -L ${DESTDIR}/usr/include/$i ]; then \
rm -f ${DESTDIR}/usr/include/$i; \
fi
@@ -95,6 +95,11 @@
cd ${.CURDIR}/../sys; \
${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 opencrypto/*.h \
${DESTDIR}/usr/include/crypto
+.if ${MACHINE_ARCH} != ${MACHINE}
+exists(${.CURDIR}/../sys/${MACHINE_ARCH}/${MACHINE})
+ cd ${.CURDIR}/../sys/${MACHINE_ARCH}/${MACHINE}; \
+ ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 *.h \
+ ${DESTDIR}/usr/include/platform
+.endif
.if exists(${.CURDIR}/../sys/${MACHINE_ARCH}/include)
cd ${.CURDIR}/../sys/${MACHINE_ARCH}/include; \
${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 *.h \
@@ -118,6 +123,10 @@
rm -rf ${DESTDIR}/usr/include/$i
ln -s ../../../sys/$i ${DESTDIR}/usr/include/$i
.endfor
+ rm -rf ${DESTDIR}/usr/include/platform
+.if ${MACHINE_ARCH} != ${MACHINE} exists(../../sys/${MACHINE_ARCH}/${MACHINE})
+ ln -s ../../sys/${MACHINE_ARCH}/${MACHINE} ${DESTDIR}/usr/include/platform
+.endif
rm -rf ${DESTDIR}/usr/include/machine
ln -s ../../sys/${MACHINE_ARCH}/include ${DESTDIR}/usr/include/machine
diff -dur src/sys/conf/kmod.mk mips/sys/conf/kmod.mk
--- src/sys/conf/kmod.mkFri Jan 24 00:35:37 2003
+++ src/sys/conf/kmod.mkThu Jan 23 22:47:11 2003
@@ -145,7 +145,7 @@
.endif
.endif
-_ILINKS=@ machine
+_ILINKS=@ machine platform
all: objwarn ${PROG}
@@ -170,10 +170,18 @@
.error can't find kernel source tree
.endif
+.if ${MACHINE_ARCH} != ${MACHINE} exists(${SYSDIR}/${MACHINE_ARCH}/${MACHINE})
+PLATFORMPATH= ${SYSDIR}/${MACHINE_ARCH}/${MACHINE}
+.else
+PLATFORMPATH= machine
+.endif
+
${_ILINKS}:
@case ${.TARGET} in \
machine) \
path=${SYSDIR}/${MACHINE_ARCH}/include ;; \
+ platform) \
+ path=${PLATFORMPATH} ;; \
@) \
path=${SYSDIR} ;; \
esac ; \
diff -dur src/usr.sbin/config/config.h mips/usr.sbin/config/config.h
--- src/usr.sbin/config/config.hThu Nov 7 21:00:20 2002
+++ src/usr.sbin/config/config.hFri Nov 1 11:16:59 2002
@@ -91,9 +91,11 @@
* being used. It uses the name of the machine in choosing
* files and directories. Thus if the name of the machine is ``i386'',
* it will build from ``Makefile.i386'' and use ``../i386/inline''
- * in the makerules, etc.
+ * in the makerules, etc. It also *may* know about a platform, which
+ * is a superconfiguration of a given machine.
*/
char *machinename;
+char *platformname;
/*
* For each machine, a set of CPU's may be specified as supported.
Only in mips/usr.sbin/config: config.o
diff -dur src/usr.sbin/config/config.y mips/usr.sbin/config/config.y
--- src/usr.sbin/config/config.yThu Nov 7 21:00:20 2002
+++ src/usr.sbin/config/config.yFri Nov 1 11:16:59 2002
@@ -14,6 +14,7 @@
%token HINTS
%token IDENT
%token MAXUSERS
+%token PLATFORM
%token PROFILE
%token OPTIONS
%token MAKEOPTIONS
@@ -135,6 +136,10 @@
cp-cpu_name = $2;
cp-cpu_next = cputype;
cputype = cp;
+ } |
+ PLATFORM Save_id
+ = {
+ platformname = $2;
} |
OPTIONS Opt_list
|
Only in mips/usr.sbin/config: lang.c
diff -dur src/usr.sbin/config/lang.l mips/usr.sbin/config/lang.l
--- src/usr.sbin/config/lang.l Thu Nov 7 21:00:20 2002
+++ src/usr.sbin/config/lang.l Fri Nov 1 11:16:59 2002
@@ -73,6 +73,7 @@
{ machine,ARCH }, /* MACHINE is defined in
