$B$&!A$5$s$X(B
$B$A$g$C$H4E$$!A(B
$B$8!!$G$9!#(B
: $B!V$8!W$5$s$O!"%1%$%s%:$NA0Ds>r7o$,K~$?$5$l$F$$$k$h$&$J0U8+$G$9$M!#(B
$B9q2H$O7P:Q3X$NNN0h$G$O$"$j$^$;$s!"7P:Q3X$r4^$`!"@/<#3X!"K!3X!"9q:]
Greetings.
Is there an existing initiative, spec, or active project to replace
sysinstall(8) with something better? I went looking recently and couldn't
find anything.
In the event no spec exists I would like to help start, or contribute to one.
TIA,
--
Dylan Carlson [[EMAIL PROTECTED]]
On Mon, Sep 02, 2002 at 06:26:50AM -0400, Dylan Carlson wrote:
Greetings.
Is there an existing initiative, spec, or active project to replace
sysinstall(8) with something better? I went looking recently and couldn't
find anything.
In the event no spec exists I would like to help
$B%"%i%C%I$G$9!#(B
$B0J2<#2E@Jg=8(B
$B#1!%%I%a%$%s%5!<%PC5:w$K$h$k%N!<%I$+$i%N!<%I$N%"%I%l%9DI5a%7%9%F%`$N(B
$BMW7oDj5A(B
$B#2!%9q2HDL2_H/9T;Y1gMW7oDj5A(B
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Fri, Aug 30, 2002 at 09:20:12AM +0100, Bruce M Simpson wrote:
Having said that though, I have had 3.0 running as well as 2.0, under
^^
Can you elaborate a bit more please? Probably your definition of 'running'
is less strict than mine.
Mark
--
On Mon, Sep 02, 2002 at 12:37:47PM +0200, Mark Santcroos wrote:
On Fri, Aug 30, 2002 at 09:20:12AM +0100, Bruce M Simpson wrote:
Having said that though, I have had 3.0 running as well as 2.0, under
^^
Can you elaborate a bit more please?
On Mon, Sep 02, 2002 at 02:23:51PM +0100, Bruce M Simpson wrote:
On Mon, Sep 02, 2002 at 12:37:47PM +0200, Mark Santcroos wrote:
On Fri, Aug 30, 2002 at 09:20:12AM +0100, Bruce M Simpson wrote:
Having said that though, I have had 3.0 running as well as 2.0, under
On Mon, Sep 02, 2002 at 03:31:59PM +0200, Stijn Hoop wrote:
You have it running?! I'm still struggling to get a vmmon module, without
[snip]
Ah. I installed the vmware2 port, *then* the vmware3 rpm (using rpm2cpio).
This just used the existing vmmon module. I assume more tweaking will
be
On Mon, Sep 02, 2002 at 02:54:06PM +0100, Bruce M Simpson wrote:
On Mon, Sep 02, 2002 at 03:31:59PM +0200, Stijn Hoop wrote:
You have it running?! I'm still struggling to get a vmmon module, without
[snip]
Ah. I installed the vmware2 port, *then* the vmware3 rpm (using rpm2cpio).
This
On Mon, Sep 02, 2002 at 04:30:30PM +0200, Stijn Hoop wrote:
This is purely speculation as to how USB devices might be handled.
Maybe someone more in the know can port the usbdevfs (as an aside, is
that a Linuxism? Why not use a standard devfs?)
usbdevfs is a Linuxism. devfs's semantics
On Sun, Sep 01, 2002 at 09:51:32PM -0700, Terry Lambert wrote:
The original claims for the tape-out on the x86-64 from AMD so
that this could happen were September 2001, with sample units
1Q2002. The AMD schedule slipped.
LOL! This slippage is *NOTHING* compared to Merced/IA-64. When I was
About 34 system calls need work (with time changes), approximately
16 without time changes. I've included a summary at the end.
The questions before us:
* What to do about time representation.
* Whether to create a new syscall vector or use the existing
In message [EMAIL PROTECTED], Matthew Dillon w
rites:
struct timeval64 {
time64_ttv_sec;
int64_t tv_frac;/* N/2^63 fractional */
};
We have this one already, and it's called bintime, except that it
correctly uses N/2^64
: struct timeval64 {
: time64_ttv_sec;
: int64_t tv_frac;/* N/2^63 fractional */
: };
:
:We have this one already, and it's called bintime, except that it
:correctly uses N/2^64 fractional the way binary computers prefer it.
:
:--
In message [EMAIL PROTECTED], Matthew Dillon w
rites:
: struct timeval64 {
: time64_ttv_sec;
: int64_t tv_frac;/* N/2^63 fractional */
: };
:
:We have this one already, and it's called bintime, except that it
:correctly uses N/2^64
:
:All right, I'll amend the proposal to use 2^64. the fractional
:element will be unsigned, the tv_sec will remain signed.
:
:That is exactly how bintime is defined :-)
:
: struct bintime {
: time_t sec;
: uint64_t frac;
: };
:
:If I had a
In message [EMAIL PROTECTED], Matthew Dillon w
rites:
Ok, we have an issue in regards to libc/user function visibility.
The bintime structures and functions are surrounded by __BSD_VISIBLE.
That was an attempt at preventive debrucification :-)
The question to you and to the list in
Matthew Dillon wrote:
About 34 system calls need work (with time changes), approximately
16 without time changes. I've included a summary at the end.
The questions before us:
* What to do about time representation.
* Whether to create a new syscall vector or
:Matt, I realize you have thought long and hard about this, but I want to
:make a couple of points.
:
:1) 32 bit i386 already has its fate sealed. AMD are switching to 64 bit,
:and Intel are doing the same (either x86-64 or their own 64 bit environment,
:depending on which rumors you listen to).
+ All this info is released under the superior PPL (Phuck Phumerola License)
About 34 system calls need work (with time changes), approximately
16 without time changes. I've included a summary at the end.
The questions before us:
* What to do about time representation.
My original proposal, before this one, was to create a separate
ABI for all the new calls, which also means creating a duplicate
set of libraries. I'm still game to do that -- it could be controlled
by a make.conf variable and selectable via a compiler option.
If we maintain
Matthew Dillon wrote:
:4) Changing time_t to 64 bit using long long on a native 32 bit platform
:is a f*cking nightmare. I've tried this and it got very nasty very quickly.
This is not what I proposed. I proposed adding new system calls to
completely and permanently fix all of
:Well, one thing that I would not be against is a clean divorce of the
:syscall layer and libc. That then gives us the freedom to implement
:alternative API selections etc at compile time pretty easily.
:
:I just really do not want to see this sort of thing turning up:
:
: time_t foo =
Oops, let me clarify what I mean by 'duplicate libraries'. I do
*NOT* mean duping the source code, I simply mean duping the
compile run in the buildworld, one for --unix32, one for --unix64,
for 32 bit platforms. 64 bit platforms would require no library
duplication at all
Matthew Dillon wrote:
Well, then what we want is a new syscall vector, duplicate libraries,
and a compiler option, and leave all the function names the same
(which means no bintime but allows us to retain everything else).
-current would release supporting both with the
Peter, you are again not reading what I'm posting carefully enough.
I said very specifically that we wouldn't be using the fractional
stuff for this case.
Additionally, you are making the assumption that --unix64 and --unix32
are so different from each other that the same
lists Now just if I could get Sendmail to not do those dang identd checks
lists all the time...
Add this to your .mc file:
define(`confTO_IDENT', `0')
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
David O'Brien wrote:
On Sun, Sep 01, 2002 at 09:51:32PM -0700, Terry Lambert wrote:
The original claims for the tape-out on the x86-64 from AMD so
that this could happen were September 2001, with sample units
1Q2002. The AMD schedule slipped.
LOL! This slippage is *NOTHING* compared
Matthew Dillon wrote:
Ok, we have an issue in regards to libc/user function visibility.
The bintime structures and functions are surrounded by __BSD_VISIBLE.
The question to you and to the list in general is: what to call the
user-visible structure. 'bintime' is a cute
Peter Wemm wrote:
Matthew Dillon wrote:
:4) Changing time_t to 64 bit using long long on a native 32 bit platform
:is a f*cking nightmare. I've tried this and it got very nasty very quickly.
This is not what I proposed. I proposed adding new system calls to
completely and
Matthew Dillon wrote:
Well, then what we want is a new syscall vector, duplicate libraries,
and a compiler option, and leave all the function names the same
(which means no bintime but allows us to retain everything else).
-current would release supporting both with the
Ah. I installed the vmware2 port, *then* the vmware3 rpm (using rpm2cpio).
This just used the existing vmmon module. I assume more tweaking will
be necessary as was the case for vmware2.
Does vmware3 really work with 'vmmon' version2?
---
VMware Workstation Error:
Could not get vmmon module
:
:Matthew Dillon wrote:
: Well, then what we want is a new syscall vector, duplicate libraries,
: and a compiler option, and leave all the function names the same
: (which means no bintime but allows us to retain everything else).
: -current would release supporting both with
In message: [EMAIL PROTECTED]
Matthew Dillon [EMAIL PROTECTED] writes:
: Peter, you are again not reading what I'm posting carefully enough.
: I said very specifically that we wouldn't be using the fractional
: stuff for this case.
I think that this is a worthy problem to
In message [EMAIL PROTECTED], M. Warner Losh writes:
In message: [EMAIL PROTECTED]
I think that this is a worthy problem to solve. But not for 5.0. [...]
Good thinking.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
35 matches
Mail list logo
