Re: How to prevent motd including os info

[Doug]

"Rodney W. Grimes" wrote:

> It dawned on me what can be done.  Look, we get all the kernel printf's
> from the dmesg output saved in a buffer and pull that out later with
> syslog, looks like we could just slip a pipe fitting into /dev/console
> that copies all it's output into the mesgbuf as well, until we smack it
> wth the ballpean and tell it to stop doing that (Either getty lanching the
> login: on ttyv0 could cause this, or something at the end of /etc/rc).
> 
> What do you think of that idea? 

I think that's a fine idea, and it's a lot cleaner than mine for a number
of reasons. Completely beyond me to code, but very nice from the design
standpoint. 

Doug


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent motd including os info

[Doug]

"Rodney W. Grimes" wrote:

> It dawned on me what can be done.  Look, we get all the kernel printf's
> from the dmesg output saved in a buffer and pull that out later with
> syslog, looks like we could just slip a pipe fitting into /dev/console
> that copies all it's output into the mesgbuf as well, until we smack it
> wth the ballpean and tell it to stop doing that (Either getty lanching the
> login: on ttyv0 could cause this, or something at the end of /etc/rc).
> 
> What do you think of that idea? 

I think that's a fine idea, and it's a lot cleaner than mine for a 
number
of reasons. Completely beyond me to code, but very nice from the design
standpoint. 

Doug


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: mbuf shortage situations (followup)

[Bosko Milekic]

Hello (again),

On Thu, 9 Sep 1999, Stas Kisel wrote:

!>> From [EMAIL PROTECTED] Thu Sep  9 16:17:27 1999
!>
!>> > Probably it is not self-evident why we HAVE to drop this connection.
!>>
!>> So what if someone manages to crash a program due to a DOS attack ?
!>> An easy one that comes to mind is syslogd.  It's often stuck in disk-wait
!>> and can easily be targetted with a large number of packets.
!>
!>1. If ever syslog used (or will use) TCP, it should drop the connection
!>which is logging data too quickly.
!>OS shouldn't kill process, only drop connection. So no crash.
!>More examples?
!>
!>2. udp_drain() may either drop all packets or intellectually select
!>"offending" socket and try to avoid deletion of "right" packets and
!>simplifying spoofing. RFC allows 1st way, but 2-nd can improve OS.
!>
!>3. Another idea. Apart from the *_drain() method. Probably I ever will
!>try to implement it somedays (quite low probability, though).
!>Set TCP window in a packets according to really available kernel
!>memory. Available memory should be distributed non-uniformly
!>between maximum number of sockets. So 1-st socket has window=
!>=64k-still_not_read_data, and 1024-th has window=MIN_WINDOW-
!>-still_not_read_data. 
!>MIN_WINDOW should be determined for max efficiency. About 2k.
!>Distribution can not be linear - it isapproximately like min(NORM*1/x,64k).
!>Exactly it can be determined via functional equation. Something like
!>\integral_0^maxsockets{dist(x)dx}=kernel_memory and several
!>conditions. (sorry for my poor TeX).
!>
!>In a case of attack new sockets will be created with a very small
!>window - about 2k.
!>
!>Please blame me as much as possible - probably I have missed some significant
!>detail.
!>Probably all this math suxx and the best is a "stair" function -
!>somebody already works on lowering TCP window, if I didn't mistaken.
!>
!>
!>--
!>Stas Kisel. UNIX, security, C, TCP/IP, Web. UNIX - the best adventure game
!>http://www.tekmetrics.com/transcript.shtml?pid=20053 http://www.crimea.edu
!>+380(652)510222,230238 ; [EMAIL PROTECTED] [EMAIL PROTECTED] ; 2:460/54.4
!>

These are all interesting ideas.

However, when I initially posted regarding this, I was
disappointed in seeing that we simply handle MGET()s, MGETHDR()s, and
MCLALLOC()s by storing a null _even_ if we are M_WAIT. What basically
ended up happening (and, the last time I checked, it's like this even in
--CURRENT), is m_retry() -- or m_retryhdr() (this is in the case of no
mbufs beings available) would simply panic().
I have produced patches (see attached -- they are seperated into
two different patches, mbuf.patch which patches kern/uipc_mbuf.c and
mbuf2.patch which patches sys/mbuf.h) that will basically tsleep() in the
case of an M_WAIT and mbuf or mbuf cluster shortage. I wanted something
that would make sure that we will get a non-NULL result when we called
with M_WAIT. Obviously, this isn't the definite solution to the DoS
problem that seemed to have become the main idea of discussion in this
thread.
However, I've kept that in mind, and I am now starting work (when
time permits) on some code which will enable us to warn the network
protocol module code that we're out of mbufs (or mbuf clusters) when the
situation occurs. This way, if we can't get anything even with m_reclaim
(which would be called from m_retry if we are M_WAIT), we could have the
protocols figure out what to drop.
I'm also aware of the possiblity of some people not liking the
fact that we tsleep() forever (e.g. tsleep(x,x,x,0)). Thus, I am open to
modifying the diffs to add a counter and have the tsleep expire every once
in a while so that finally, when the counter would expire, we would return
a deffinate null _even_ if we are M_WAIT, but this can only be implemented
if we make sure that ALL the MGET and company callers check for this
(which would be annoying to do).


Cheers,
Bosko Milekic.



--- /usr/src/sys/kern.old/uipc_mbuf.c   Wed Sep  8 20:45:50 1999
+++ /usr/src/sys/kern/uipc_mbuf.c   Sun Sep 12 22:44:23 1999
@@ -60,6 +60,8 @@
 intmax_hdr;
 intmax_datalen;
 
+static int m_mballoc_wid = 0, m_clalloc_wid = 0;
+
 SYSCTL_INT(_kern_ipc, KIPC_MAX_LINKHDR, max_linkhdr, CTLFLAG_RW,
   &max_linkhdr, 0, "");
 SYSCTL_INT(_kern_ipc, KIPC_MAX_PROTOHDR, max_protohdr, CTLFLAG_RW,
@@ -153,6 +155,57 @@
return (1);
 }
 
+/*
+ * Function used for waiting on some mbuf to be freed and, upon wakeup,
+ * to go get that mbuf and use it.
+ */
+struct mbuf *
+m_mballoc_wait(caller, type)
+   int caller;
+   int type;
+{
+   struct mbuf *p;
+
+RetryFetch:
+   /* Sleep here until something's available. */
+   m_mballoc_wid++;
+   tsleep(&m_mballoc_wid, PVM, "mballc", 0);
+   
+   /*
+* Now that we (think) that we've got something, we will redo an
+* MGET, but avoid getting into another instance of m_mballoc_wait()
+* We do t

Re: mbuf shortage situations (followup)

[Bosko Milekic]

Hello (again),

On Thu, 9 Sep 1999, Stas Kisel wrote:

!>> From ava...@cheops.anu.edu.au Thu Sep  9 16:17:27 1999
!>
!>> > Probably it is not self-evident why we HAVE to drop this connection.
!>>
!>> So what if someone manages to crash a program due to a DOS attack ?
!>> An easy one that comes to mind is syslogd.  It's often stuck in disk-wait
!>> and can easily be targetted with a large number of packets.
!>
!>1. If ever syslog used (or will use) TCP, it should drop the connection
!>which is logging data too quickly.
!>OS shouldn't kill process, only drop connection. So no crash.
!>More examples?
!>
!>2. udp_drain() may either drop all packets or intellectually select
!>"offending" socket and try to avoid deletion of "right" packets and
!>simplifying spoofing. RFC allows 1st way, but 2-nd can improve OS.
!>
!>3. Another idea. Apart from the *_drain() method. Probably I ever will
!>try to implement it somedays (quite low probability, though).
!>Set TCP window in a packets according to really available kernel
!>memory. Available memory should be distributed non-uniformly
!>between maximum number of sockets. So 1-st socket has window=
!>=64k-still_not_read_data, and 1024-th has window=MIN_WINDOW-
!>-still_not_read_data. 
!>MIN_WINDOW should be determined for max efficiency. About 2k.
!>Distribution can not be linear - it isapproximately like min(NORM*1/x,64k).
!>Exactly it can be determined via functional equation. Something like
!>\integral_0^maxsockets{dist(x)dx}=kernel_memory and several
!>conditions. (sorry for my poor TeX).
!>
!>In a case of attack new sockets will be created with a very small
!>window - about 2k.
!>
!>Please blame me as much as possible - probably I have missed some significant
!>detail.
!>Probably all this math suxx and the best is a "stair" function -
!>somebody already works on lowering TCP window, if I didn't mistaken.
!>
!>
!>--
!>Stas Kisel. UNIX, security, C, TCP/IP, Web. UNIX - the best adventure game
!>http://www.tekmetrics.com/transcript.shtml?pid=20053 http://www.crimea.edu
!>+380(652)510222,230238 ; s...@crimea.edu s...@sonet.crimea.ua ; 2:460/54.4
!>

These are all interesting ideas.

However, when I initially posted regarding this, I was
disappointed in seeing that we simply handle MGET()s, MGETHDR()s, and
MCLALLOC()s by storing a null _even_ if we are M_WAIT. What basically
ended up happening (and, the last time I checked, it's like this even in
--CURRENT), is m_retry() -- or m_retryhdr() (this is in the case of no
mbufs beings available) would simply panic().
I have produced patches (see attached -- they are seperated into
two different patches, mbuf.patch which patches kern/uipc_mbuf.c and
mbuf2.patch which patches sys/mbuf.h) that will basically tsleep() in the
case of an M_WAIT and mbuf or mbuf cluster shortage. I wanted something
that would make sure that we will get a non-NULL result when we called
with M_WAIT. Obviously, this isn't the definite solution to the DoS
problem that seemed to have become the main idea of discussion in this
thread.
However, I've kept that in mind, and I am now starting work (when
time permits) on some code which will enable us to warn the network
protocol module code that we're out of mbufs (or mbuf clusters) when the
situation occurs. This way, if we can't get anything even with m_reclaim
(which would be called from m_retry if we are M_WAIT), we could have the
protocols figure out what to drop.
I'm also aware of the possiblity of some people not liking the
fact that we tsleep() forever (e.g. tsleep(x,x,x,0)). Thus, I am open to
modifying the diffs to add a counter and have the tsleep expire every once
in a while so that finally, when the counter would expire, we would return
a deffinate null _even_ if we are M_WAIT, but this can only be implemented
if we make sure that ALL the MGET and company callers check for this
(which would be annoying to do).


Cheers,
Bosko Milekic.

--- /usr/src/sys/kern.old/uipc_mbuf.c   Wed Sep  8 20:45:50 1999
+++ /usr/src/sys/kern/uipc_mbuf.c   Sun Sep 12 22:44:23 1999
@@ -60,6 +60,8 @@
 intmax_hdr;
 intmax_datalen;
 
+static int m_mballoc_wid = 0, m_clalloc_wid = 0;
+
 SYSCTL_INT(_kern_ipc, KIPC_MAX_LINKHDR, max_linkhdr, CTLFLAG_RW,
   &max_linkhdr, 0, "");
 SYSCTL_INT(_kern_ipc, KIPC_MAX_PROTOHDR, max_protohdr, CTLFLAG_RW,
@@ -153,6 +155,57 @@
return (1);
 }
 
+/*
+ * Function used for waiting on some mbuf to be freed and, upon wakeup,
+ * to go get that mbuf and use it.
+ */
+struct mbuf *
+m_mballoc_wait(caller, type)
+   int caller;
+   int type;
+{
+   struct mbuf *p;
+
+RetryFetch:
+   /* Sleep here until something's available. */
+   m_mballoc_wid++;
+   tsleep(&m_mballoc_wid, PVM, "mballc", 0);
+   
+   /*
+* Now that we (think) that we've got something, we will redo an
+* MGET, but avoid getting into another instance of m_mballoc_wait()
+* We do this by defining this function

Re: Wall Street Journal on Open source OS (9/10/99)

[Garance A Drosihn]

At 10:42 AM -0700 9/10/99, Sanjay Waghray wrote:
>Attached is an article from the Wall Street Journal Online Edition.
>
>---
>
>September 10, 1999
>
>   Beyond Linux, Free Systems
>   Do Their Bit to Build Web
>
>   By LEE GOMES
>   Staff Reporter of THE WALL STREET JOURNAL

Unless you got the "express prior written consent of Dow Jones",
as stated in the "Terms of Use" of their web site, it would be
much better to point people at:
  - - - -
There's also a link to the online version at
http://freebsd.tesserae.com/
  - - - -
than to copy the entire article and mail it to everyone on this
mailing list.


---
Garance Alistair Drosehn   =   [EMAIL PROTECTED]
Senior Systems Programmer  or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Wall Street Journal on Open source OS (9/10/99)

[Garance A Drosihn]

At 10:42 AM -0700 9/10/99, Sanjay Waghray wrote:

Attached is an article from the Wall Street Journal Online Edition.

---

September 10, 1999

  Beyond Linux, Free Systems
  Do Their Bit to Build Web

  By LEE GOMES
  Staff Reporter of THE WALL STREET JOURNAL


Unless you got the "express prior written consent of Dow Jones",
as stated in the "Terms of Use" of their web site, it would be
much better to point people at:
 - - - -
There's also a link to the online version at
http://freebsd.tesserae.com/
 - - - -
than to copy the entire article and mail it to everyone on this
mailing list.


---
Garance Alistair Drosehn   =   g...@eclipse.acs.rpi.edu
Senior Systems Programmer  or  dro...@rpi.edu
Rensselaer Polytechnic Institute


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent motd including os info

[Rodney W. Grimes]

> "Rodney W. Grimes" wrote:
> > 
> > > [moving to -hackers]
> > [I'm going to loose the rest of this thread since I am not on hackers :-(]
> 
>   Shame on you. :)

The volume of mail became too high for my time a long while ago.  :-(

> > > "Rodney W. Grimes" <[EMAIL PROTECTED]> writes:
> 
> > Actually I would like _all_ the output from /etc/rc* to be avaliable
> > after boot. 
> 
>   One of the things discussed on -hackers recently is my rc* (et al) cleanup
> effort. You can see the results at http://gorean.org/rcfiles/. If I can get
> the current set of patches committed the next step in my proposal is to
> change as many of the 'echo' statements as humanly possible to use 'logger'
> instead. This is somewhat controversial because it will (for some items)
> require moving 'logger' to /bin, but I think it's worth it. 

I don't like that idea, don't get me wrong, it's not the moving of logger
to /bin that bothers me, it just seems like this is using the splitting
mall for what a ballpean hammer could do.

It dawned on me what can be done.  Look, we get all the kernel printf's
from the dmesg output saved in a buffer and pull that out later with
syslog, looks like we could just slip a pipe fitting into /dev/console
that copies all it's output into the mesgbuf as well, until we smack it
wth the ballpean and tell it to stop doing that (Either getty lanching the
login: on ttyv0 could cause this, or something at the end of /etc/rc).

What do you think of that idea?  I think this is what HPUX does, as I do
know I can get the complete console output from a boot on it.

> 
> > This would be a big win for remote admining and trying
> > to figure out what went wrong during the last boot without having to
> > drive down and hook up a console of some form.  I know we could hang
> > serial consoles on all of them, but why spend money on hardware when
> > the problem can be solved with software :-).
> 
>   I agree, both that it would be a huge benefit for remote admins (I'm one
> too) and that there are some problems that a serial console doesn't solve
> where having a hard copy is your best bet (such as jr. asst. cow orker
> rebooted a machine he should not have, and now it's borked and no one knows
> why). 

Been there, fixed that, and Jr's now missing his left pointer finger
so he only types ``eoo'' when he tries a reboot :-) :-)

> 
> > >  fsck_output="$(/sbin/fsck -p)"
> > >  /sbin/mount -at nonfs
> > >  echo "${fsck_output}" >/var/run/fsck.boot
> > >
> > > but then you wouldn't be able to see the output while it runs. The
> > > only solution I can think of is the following:
> > >
> > >  fsck_output="$(/sbin/fsck -p | /bin/tee /dev/console)"
> > >  /sbin/mount -at nonfs
> > >  echo "${fsck_output}" >/var/run/fsck.boot
> > >
> > > but I don't expect people to be happy about moving tee(1) from
> > > /usr/bin to /bin.
> 
>   Another possible solution to this would be giving fsck a flag to
> copy it's
> output to a file, STDOUT, or what have you. Since the rest of the cases
> could be handled with 'logger' and/or redirction we wouldn't have to bring
> 'tee' into /bin. 

Adding a flag to fsck to duplicate it's output is even worse than bringing
tee(1) to bin, it's putting tee(1) inside fsck(8) :-(.

-- 
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent motd including os info

[Rodney W. Grimes]

> "Rodney W. Grimes" wrote:
> > 
> > > [moving to -hackers]
> > [I'm going to loose the rest of this thread since I am not on hackers :-(]
> 
>   Shame on you. :)

The volume of mail became too high for my time a long while ago.  :-(

> > > "Rodney W. Grimes"  writes:
> 
> > Actually I would like _all_ the output from /etc/rc* to be avaliable
> > after boot. 
> 
>   One of the things discussed on -hackers recently is my rc* (et al) 
> cleanup
> effort. You can see the results at http://gorean.org/rcfiles/. If I can get
> the current set of patches committed the next step in my proposal is to
> change as many of the 'echo' statements as humanly possible to use 'logger'
> instead. This is somewhat controversial because it will (for some items)
> require moving 'logger' to /bin, but I think it's worth it. 

I don't like that idea, don't get me wrong, it's not the moving of logger
to /bin that bothers me, it just seems like this is using the splitting
mall for what a ballpean hammer could do.

It dawned on me what can be done.  Look, we get all the kernel printf's
from the dmesg output saved in a buffer and pull that out later with
syslog, looks like we could just slip a pipe fitting into /dev/console
that copies all it's output into the mesgbuf as well, until we smack it
wth the ballpean and tell it to stop doing that (Either getty lanching the
login: on ttyv0 could cause this, or something at the end of /etc/rc).

What do you think of that idea?  I think this is what HPUX does, as I do
know I can get the complete console output from a boot on it.

> 
> > This would be a big win for remote admining and trying
> > to figure out what went wrong during the last boot without having to
> > drive down and hook up a console of some form.  I know we could hang
> > serial consoles on all of them, but why spend money on hardware when
> > the problem can be solved with software :-).
> 
>   I agree, both that it would be a huge benefit for remote admins (I'm one
> too) and that there are some problems that a serial console doesn't solve
> where having a hard copy is your best bet (such as jr. asst. cow orker
> rebooted a machine he should not have, and now it's borked and no one knows
> why). 

Been there, fixed that, and Jr's now missing his left pointer finger
so he only types ``eoo'' when he tries a reboot :-) :-)

> 
> > >  fsck_output="$(/sbin/fsck -p)"
> > >  /sbin/mount -at nonfs
> > >  echo "${fsck_output}" >/var/run/fsck.boot
> > >
> > > but then you wouldn't be able to see the output while it runs. The
> > > only solution I can think of is the following:
> > >
> > >  fsck_output="$(/sbin/fsck -p | /bin/tee /dev/console)"
> > >  /sbin/mount -at nonfs
> > >  echo "${fsck_output}" >/var/run/fsck.boot
> > >
> > > but I don't expect people to be happy about moving tee(1) from
> > > /usr/bin to /bin.
> 
>   Another possible solution to this would be giving fsck a flag to
> copy it's
> output to a file, STDOUT, or what have you. Since the rest of the cases
> could be handled with 'logger' and/or redirction we wouldn't have to bring
> 'tee' into /bin. 

Adding a flag to fsck to duplicate it's output is even worse than bringing
tee(1) to bin, it's putting tee(1) inside fsck(8) :-(.

-- 
Rod Grimes - KD7CAX - (RWG25)rgri...@gndrsh.dnsmgr.net


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent motd including os info

[Doug]

"Rodney W. Grimes" wrote:
> 
> > [moving to -hackers]
> [I'm going to loose the rest of this thread since I am not on hackers :-(]

Shame on you. :)

> > "Rodney W. Grimes" <[EMAIL PROTECTED]> writes:

> Actually I would like _all_ the output from /etc/rc* to be avaliable
> after boot. 

One of the things discussed on -hackers recently is my rc* (et al) cleanup
effort. You can see the results at http://gorean.org/rcfiles/. If I can get
the current set of patches committed the next step in my proposal is to
change as many of the 'echo' statements as humanly possible to use 'logger'
instead. This is somewhat controversial because it will (for some items)
require moving 'logger' to /bin, but I think it's worth it. 

> This would be a big win for remote admining and trying
> to figure out what went wrong during the last boot without having to
> drive down and hook up a console of some form.  I know we could hang
> serial consoles on all of them, but why spend money on hardware when
> the problem can be solved with software :-).

I agree, both that it would be a huge benefit for remote admins (I'm one
too) and that there are some problems that a serial console doesn't solve
where having a hard copy is your best bet (such as jr. asst. cow orker
rebooted a machine he should not have, and now it's borked and no one knows
why). 

> >  fsck_output="$(/sbin/fsck -p)"
> >  /sbin/mount -at nonfs
> >  echo "${fsck_output}" >/var/run/fsck.boot
> >
> > but then you wouldn't be able to see the output while it runs. The
> > only solution I can think of is the following:
> >
> >  fsck_output="$(/sbin/fsck -p | /bin/tee /dev/console)"
> >  /sbin/mount -at nonfs
> >  echo "${fsck_output}" >/var/run/fsck.boot
> >
> > but I don't expect people to be happy about moving tee(1) from
> > /usr/bin to /bin.

Another possible solution to this would be giving fsck a flag to copy it's
output to a file, STDOUT, or what have you. Since the rest of the cases
could be handled with 'logger' and/or redirction we wouldn't have to bring
'tee' into /bin. 

Doug


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent motd including os info

[Doug]

"Rodney W. Grimes" wrote:
> 
> > [moving to -hackers]
> [I'm going to loose the rest of this thread since I am not on hackers :-(]

Shame on you. :)

> > "Rodney W. Grimes"  writes:

> Actually I would like _all_ the output from /etc/rc* to be avaliable
> after boot. 

One of the things discussed on -hackers recently is my rc* (et al) 
cleanup
effort. You can see the results at http://gorean.org/rcfiles/. If I can get
the current set of patches committed the next step in my proposal is to
change as many of the 'echo' statements as humanly possible to use 'logger'
instead. This is somewhat controversial because it will (for some items)
require moving 'logger' to /bin, but I think it's worth it. 

> This would be a big win for remote admining and trying
> to figure out what went wrong during the last boot without having to
> drive down and hook up a console of some form.  I know we could hang
> serial consoles on all of them, but why spend money on hardware when
> the problem can be solved with software :-).

I agree, both that it would be a huge benefit for remote admins (I'm one
too) and that there are some problems that a serial console doesn't solve
where having a hard copy is your best bet (such as jr. asst. cow orker
rebooted a machine he should not have, and now it's borked and no one knows
why). 

> >  fsck_output="$(/sbin/fsck -p)"
> >  /sbin/mount -at nonfs
> >  echo "${fsck_output}" >/var/run/fsck.boot
> >
> > but then you wouldn't be able to see the output while it runs. The
> > only solution I can think of is the following:
> >
> >  fsck_output="$(/sbin/fsck -p | /bin/tee /dev/console)"
> >  /sbin/mount -at nonfs
> >  echo "${fsck_output}" >/var/run/fsck.boot
> >
> > but I don't expect people to be happy about moving tee(1) from
> > /usr/bin to /bin.

Another possible solution to this would be giving fsck a flag to copy 
it's
output to a file, STDOUT, or what have you. Since the rest of the cases
could be handled with 'logger' and/or redirction we wouldn't have to bring
'tee' into /bin. 

Doug


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: X mailers (was Re: ANNOUNCE: Linux ABI/SDK standards for Ope

[Daniel O'Connor]

On 10-Sep-99 Vince Vielhaber wrote:
> > It claims to do IMAP4, but it just fetches all messages from the server
> > (and by default deleting it from the server). There are very few good IMAP4
> > clients out there :-(
>  
>  xfmail?  Doesn't do that here and I use it daily for all of my internal
>  stuff.

No.. I meant that XFMail worked properly, but Pine didn't.
 
---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum

 PGP signature

Re: X mailers (was Re: ANNOUNCE: Linux ABI/SDK standards for Ope

[Daniel O'Connor]

On 10-Sep-99 Vince Vielhaber wrote:
> > It claims to do IMAP4, but it just fetches all messages from the server
> > (and by default deleting it from the server). There are very few good IMAP4
> > clients out there :-(
>  
>  xfmail?  Doesn't do that here and I use it daily for all of my internal
>  stuff.

No.. I meant that XFMail worked properly, but Pine didn't.
 
---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum


pgpwFxWeuqSa6.pgp
Description: PGP signature

mounting a partition more than once

[Tony Finch]

Is there a reason for disallowing concurrent read-only mounts of the
same disk device? i.e. would things go pear-shaped if I added this
capability? 

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

mounting a partition more than once

[Tony Finch]

Is there a reason for disallowing concurrent read-only mounts of the
same disk device? i.e. would things go pear-shaped if I added this
capability? 

Tony.
-- 
f.a.n.finchf...@demon.netd...@dotat.ate pluribus unix


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent motd including os info

[Rodney W. Grimes]

> "Rodney W. Grimes" <[EMAIL PROTECTED]> writes:
> > > One thing I'd like very much, though, would be to have the output of
> > > fsck -p logged somehow [...]
> > Actually I would like _all_ the output from /etc/rc* to be avaliable
> > after boot.  It should be in the syscons scroll back buffer, [...]
> 
> No. The scrollback may be too short (especially after an fsck of a
> large filesystem after a crash), and it may even be empty (if you put
> something like VESA_132x60 in allscreens_flags in rc.conf)

We can tune the size of the scroll back buffer can't we?  And fsck output
even after a crash is usually not that long, if it gets long it usually
has more problems than fsck -p can deal with and stops any way.

Why does switching display mode screw up the scroll back buffer?  That
sounds broken to me.

> 
> > And solving only 1 piece of output from /etc/rc is an incomplete
> > concept.  I really like to know if ntpdate stepped my clock 23 seconds
> > for some reason, thats why this (usually means a clock chip has gone
> > zonkers :-)):
> 
> Doesn't ntpdate log what it does with syslog?  If not, I think
> whichever syscall it is that ntpdate uses to adjust the time should
> printf() or log() the change.

If you give it the -s option, yes it will syslog it.  But doing that
to everything in /etc/rc* seems like a pain in the *ss...


-- 
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent motd including os info

[Rodney W. Grimes]

> "Rodney W. Grimes"  writes:
> > > One thing I'd like very much, though, would be to have the output of
> > > fsck -p logged somehow [...]
> > Actually I would like _all_ the output from /etc/rc* to be avaliable
> > after boot.  It should be in the syscons scroll back buffer, [...]
> 
> No. The scrollback may be too short (especially after an fsck of a
> large filesystem after a crash), and it may even be empty (if you put
> something like VESA_132x60 in allscreens_flags in rc.conf)

We can tune the size of the scroll back buffer can't we?  And fsck output
even after a crash is usually not that long, if it gets long it usually
has more problems than fsck -p can deal with and stops any way.

Why does switching display mode screw up the scroll back buffer?  That
sounds broken to me.

> 
> > And solving only 1 piece of output from /etc/rc is an incomplete
> > concept.  I really like to know if ntpdate stepped my clock 23 seconds
> > for some reason, thats why this (usually means a clock chip has gone
> > zonkers :-)):
> 
> Doesn't ntpdate log what it does with syslog?  If not, I think
> whichever syscall it is that ntpdate uses to adjust the time should
> printf() or log() the change.

If you give it the -s option, yes it will syslog it.  But doing that
to everything in /etc/rc* seems like a pain in the *ss...


-- 
Rod Grimes - KD7CAX - (RWG25)rgri...@gndrsh.dnsmgr.net


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: damn ATX power supplies...

[Tony Finch]

Peter Wemm <[EMAIL PROTECTED]> wrote:
>
>On newer motherboards, it's addressable on the SMB bus (along with
>the SIMMS, the LM78/LM75/etc, the embedded LM75 in the newer CPU,
>etc). Anyway, the newer devices are programmable to do things like
>the 4-second power off delay, auto-on with AC, maintain previous
>state when AC restored, alarm clock time auto start, as well as the
>usual "turn off now" command from the APM bios.

Is there any software out there that speaks to /dev/smb?
intelligently? We have some Dell boxen with loads of SMB stuff in
them; it'd be nice to be able to see what's going on there.

Alternatively, are there freely-available SMB specs?

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: damn ATX power supplies...

[Tony Finch]

Peter Wemm  wrote:
>
>On newer motherboards, it's addressable on the SMB bus (along with
>the SIMMS, the LM78/LM75/etc, the embedded LM75 in the newer CPU,
>etc). Anyway, the newer devices are programmable to do things like
>the 4-second power off delay, auto-on with AC, maintain previous
>state when AC restored, alarm clock time auto start, as well as the
>usual "turn off now" command from the APM bios.

Is there any software out there that speaks to /dev/smb?
intelligently? We have some Dell boxen with loads of SMB stuff in
them; it'd be nice to be able to see what's going on there.

Alternatively, are there freely-available SMB specs?

Tony.
-- 
f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to go about making a compiler port

[Andrew Reilly]

On Sun, Sep 12, 1999 at 02:47:21PM +0200, Jeroen Ruigrok/Asmodai wrote:
> * Simon Marlow ([EMAIL PROTECTED]) [990912 13:05]:
> 
> >I'd like to make a port for our Haskell compiler, GHC (see
> >http://research.microsoft.com/users/t-simonm/ghc).  There are some subtle
> >problems with this:
> >
> > - GHC depends on itself.  That is, you need GHC
> >   installed in order to build GHC.
> > - GHC depends on Happy, our parser generator.
> > - Happy depends on GHC (it's written in Haskell).
> 
> >So, one solution would be to provide a binary port, say ghc-bin, which would
> >install a binary distribution.  I checked the modula-3 port, and it doesn't
> >seem to have a binary port, so what's the accepted way of doing this?

It's not a port yet, but compiles from it's distribuiton without
problems: SmallEiffel is also written in itself, but has a
natural intermediate compilation phase which is ANSI C.  The
distribution just includes the C, from which the compiler and
tools is built.

That seems to work pretty well.

-- 
Andrew


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to go about making a compiler port

[Andrew Reilly]

On Sun, Sep 12, 1999 at 02:47:21PM +0200, Jeroen Ruigrok/Asmodai wrote:
> * Simon Marlow (simon...@microsoft.com) [990912 13:05]:
> 
> >I'd like to make a port for our Haskell compiler, GHC (see
> >http://research.microsoft.com/users/t-simonm/ghc).  There are some subtle
> >problems with this:
> >
> > - GHC depends on itself.  That is, you need GHC
> >   installed in order to build GHC.
> > - GHC depends on Happy, our parser generator.
> > - Happy depends on GHC (it's written in Haskell).
> 
> >So, one solution would be to provide a binary port, say ghc-bin, which would
> >install a binary distribution.  I checked the modula-3 port, and it doesn't
> >seem to have a binary port, so what's the accepted way of doing this?

It's not a port yet, but compiles from it's distribuiton without
problems: SmallEiffel is also written in itself, but has a
natural intermediate compilation phase which is ANSI C.  The
distribution just includes the C, from which the compiler and
tools is built.

That seems to work pretty well.

-- 
Andrew


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent motd including os info

[Dag-Erling Smorgrav]

"Rodney W. Grimes" <[EMAIL PROTECTED]> writes:
> > One thing I'd like very much, though, would be to have the output of
> > fsck -p logged somehow [...]
> Actually I would like _all_ the output from /etc/rc* to be avaliable
> after boot.  It should be in the syscons scroll back buffer, [...]

No. The scrollback may be too short (especially after an fsck of a
large filesystem after a crash), and it may even be empty (if you put
something like VESA_132x60 in allscreens_flags in rc.conf)

> And solving only 1 piece of output from /etc/rc is an incomplete
> concept.  I really like to know if ntpdate stepped my clock 23 seconds
> for some reason, thats why this (usually means a clock chip has gone
> zonkers :-)):

Doesn't ntpdate log what it does with syslog? If not, I think
whichever syscall it is that ntpdate uses to adjust the time should
printf() or log() the change.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent motd including os info

[Dag-Erling Smorgrav]

"Rodney W. Grimes"  writes:
> > One thing I'd like very much, though, would be to have the output of
> > fsck -p logged somehow [...]
> Actually I would like _all_ the output from /etc/rc* to be avaliable
> after boot.  It should be in the syscons scroll back buffer, [...]

No. The scrollback may be too short (especially after an fsck of a
large filesystem after a crash), and it may even be empty (if you put
something like VESA_132x60 in allscreens_flags in rc.conf)

> And solving only 1 piece of output from /etc/rc is an incomplete
> concept.  I really like to know if ntpdate stepped my clock 23 seconds
> for some reason, thats why this (usually means a clock chip has gone
> zonkers :-)):

Doesn't ntpdate log what it does with syslog? If not, I think
whichever syscall it is that ntpdate uses to adjust the time should
printf() or log() the change.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent motd including os info

[Rodney W. Grimes]

> [moving to -hackers]
[I'm going to loose the rest of this thread since I am not on hackers :-(]

> 
> "Rodney W. Grimes" <[EMAIL PROTECTED]> writes:
> > So when can we see this commited
> 
> Already done (-CURRENT only). I've had requests (notably from Yan
> Koum) to backport it to -STABLE, but I won't do it so close to a
> release.

I've already done the ``backport'', but your correct in that it is
a wee bit close to release, actually too late as we are in code freeze
and this is a new feature :-).

> 
> >  the only thing I would like
> > changed is actually a general format of output change in /etc/rc.network,
> > if you have a few of the ``tcp_*'' knobs set the line length gets
> > a bit long, could be change the ``echo -n'''s to ``echo \t'' and loose
> > the trailing ``echo '.'''.  
> 
> I don't consider that much of a problem, except in cases where
> individual scripts / options produce output which breaks the line
> (this is mostly a problem with ports). I wouldn't mind the changes you
> suggest, but I don't care enough to actually go ahead and do it.
> 
> One thing I'd like very much, though, would be to have the output of
> fsck -p logged somehow - but since we don't have anything mounted rw
> when fsck runs, it's a bit hard to log to disk. You could of course
> do something like this:

Actually I would like _all_ the output from /etc/rc* to be avaliable
after boot.  It should be in the syscons scroll back buffer, we just
need a little program to go grab it and stuff it away at the end of
/etc/rc runs.  This would be a big win for remote admining and trying
to figure out what went wrong during the last boot without having to
drive down and hook up a console of some form.  I know we could hang
serial consoles on all of them, but why spend money on hardware when
the problem can be solved with software :-).

> 
>  fsck_output="$(/sbin/fsck -p)"
>  /sbin/mount -at nonfs
>  echo "${fsck_output}" >/var/run/fsck.boot
> 
> but then you wouldn't be able to see the output while it runs. The
> only solution I can think of is the following:
> 
>  fsck_output="$(/sbin/fsck -p | /bin/tee /dev/console)"
>  /sbin/mount -at nonfs
>  echo "${fsck_output}" >/var/run/fsck.boot
> 
> but I don't expect people to be happy about moving tee(1) from
> /usr/bin to /bin.

And solving only 1 piece of output from /etc/rc is an incomplete
concept.  I really like to know if ntpdate stepped my clock 23 seconds
for some reason, thats why this (usually means a clock chip has gone
zonkers :-)):
Index: rc.network
===
RCS file: /home/ncvs/src/etc/rc.network,v
retrieving revision 1.39.2.11
diff -u -r1.39.2.11 rc.network
--- rc.network  1999/09/03 08:57:26 1.39.2.11
+++ rc.network  1999/09/12 19:02:01
@@ -257,7 +257,7 @@
 fi
 
 if [ "X${ntpdate_enable}" = X"YES" ]; then
-   echo -n ' ntpdate'; ${ntpdate_program} ${ntpdate_flags} >/dev/null 2>&1
+   echo -n ' ntpdate'; ${ntpdate_program} ${ntpdate_flags} >>/var/log/ntpdate 
+2>&1
 fi
 
 if [ "X${xntpd_enable}" = X"YES" ]; then

And a whole slew of others... they just has to be a better way!!


-- 
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent motd including os info

[Rodney W. Grimes]

> [moving to -hackers]
[I'm going to loose the rest of this thread since I am not on hackers :-(]

> 
> "Rodney W. Grimes"  writes:
> > So when can we see this commited
> 
> Already done (-CURRENT only). I've had requests (notably from Yan
> Koum) to backport it to -STABLE, but I won't do it so close to a
> release.

I've already done the ``backport'', but your correct in that it is
a wee bit close to release, actually too late as we are in code freeze
and this is a new feature :-).

> 
> >  the only thing I would like
> > changed is actually a general format of output change in /etc/rc.network,
> > if you have a few of the ``tcp_*'' knobs set the line length gets
> > a bit long, could be change the ``echo -n'''s to ``echo \t'' and loose
> > the trailing ``echo '.'''.  
> 
> I don't consider that much of a problem, except in cases where
> individual scripts / options produce output which breaks the line
> (this is mostly a problem with ports). I wouldn't mind the changes you
> suggest, but I don't care enough to actually go ahead and do it.
> 
> One thing I'd like very much, though, would be to have the output of
> fsck -p logged somehow - but since we don't have anything mounted rw
> when fsck runs, it's a bit hard to log to disk. You could of course
> do something like this:

Actually I would like _all_ the output from /etc/rc* to be avaliable
after boot.  It should be in the syscons scroll back buffer, we just
need a little program to go grab it and stuff it away at the end of
/etc/rc runs.  This would be a big win for remote admining and trying
to figure out what went wrong during the last boot without having to
drive down and hook up a console of some form.  I know we could hang
serial consoles on all of them, but why spend money on hardware when
the problem can be solved with software :-).

> 
>  fsck_output="$(/sbin/fsck -p)"
>  /sbin/mount -at nonfs
>  echo "${fsck_output}" >/var/run/fsck.boot
> 
> but then you wouldn't be able to see the output while it runs. The
> only solution I can think of is the following:
> 
>  fsck_output="$(/sbin/fsck -p | /bin/tee /dev/console)"
>  /sbin/mount -at nonfs
>  echo "${fsck_output}" >/var/run/fsck.boot
> 
> but I don't expect people to be happy about moving tee(1) from
> /usr/bin to /bin.

And solving only 1 piece of output from /etc/rc is an incomplete
concept.  I really like to know if ntpdate stepped my clock 23 seconds
for some reason, thats why this (usually means a clock chip has gone
zonkers :-)):
Index: rc.network
===
RCS file: /home/ncvs/src/etc/rc.network,v
retrieving revision 1.39.2.11
diff -u -r1.39.2.11 rc.network
--- rc.network  1999/09/03 08:57:26 1.39.2.11
+++ rc.network  1999/09/12 19:02:01
@@ -257,7 +257,7 @@
 fi
 
 if [ "X${ntpdate_enable}" = X"YES" ]; then
-   echo -n ' ntpdate'; ${ntpdate_program} ${ntpdate_flags} >/dev/null 
2>&1
+   echo -n ' ntpdate'; ${ntpdate_program} ${ntpdate_flags} 
>>/var/log/ntpdate 2>&1
 fi
 
 if [ "X${xntpd_enable}" = X"YES" ]; then

And a whole slew of others... they just has to be a better way!!


-- 
Rod Grimes - KD7CAX - (RWG25)rgri...@gndrsh.dnsmgr.net


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent motd including os info

[Dag-Erling Smorgrav]

[moving to -hackers]

"Rodney W. Grimes" <[EMAIL PROTECTED]> writes:
> So when can we see this commited

Already done (-CURRENT only). I've had requests (notably from Yan
Koum) to backport it to -STABLE, but I won't do it so close to a
release.

>  the only thing I would like
> changed is actually a general format of output change in /etc/rc.network,
> if you have a few of the ``tcp_*'' knobs set the line length gets
> a bit long, could be change the ``echo -n'''s to ``echo \t'' and loose
> the trailing ``echo '.'''.  

I don't consider that much of a problem, except in cases where
individual scripts / options produce output which breaks the line
(this is mostly a problem with ports). I wouldn't mind the changes you
suggest, but I don't care enough to actually go ahead and do it.

One thing I'd like very much, though, would be to have the output of
fsck -p logged somehow - but since we don't have anything mounted rw
when fsck runs, it's a bit hard to log to disk. You could of course
do something like this:

 fsck_output="$(/sbin/fsck -p)"
 /sbin/mount -at nonfs
 echo "${fsck_output}" >/var/run/fsck.boot

but then you wouldn't be able to see the output while it runs. The
only solution I can think of is the following:

 fsck_output="$(/sbin/fsck -p | /bin/tee /dev/console)"
 /sbin/mount -at nonfs
 echo "${fsck_output}" >/var/run/fsck.boot

but I don't expect people to be happy about moving tee(1) from
/usr/bin to /bin.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to prevent motd including os info

[Dag-Erling Smorgrav]

[moving to -hackers]

"Rodney W. Grimes"  writes:
> So when can we see this commited

Already done (-CURRENT only). I've had requests (notably from Yan
Koum) to backport it to -STABLE, but I won't do it so close to a
release.

>  the only thing I would like
> changed is actually a general format of output change in /etc/rc.network,
> if you have a few of the ``tcp_*'' knobs set the line length gets
> a bit long, could be change the ``echo -n'''s to ``echo \t'' and loose
> the trailing ``echo '.'''.  

I don't consider that much of a problem, except in cases where
individual scripts / options produce output which breaks the line
(this is mostly a problem with ports). I wouldn't mind the changes you
suggest, but I don't care enough to actually go ahead and do it.

One thing I'd like very much, though, would be to have the output of
fsck -p logged somehow - but since we don't have anything mounted rw
when fsck runs, it's a bit hard to log to disk. You could of course
do something like this:

 fsck_output="$(/sbin/fsck -p)"
 /sbin/mount -at nonfs
 echo "${fsck_output}" >/var/run/fsck.boot

but then you wouldn't be able to see the output while it runs. The
only solution I can think of is the following:

 fsck_output="$(/sbin/fsck -p | /bin/tee /dev/console)"
 /sbin/mount -at nonfs
 echo "${fsck_output}" >/var/run/fsck.boot

but I don't expect people to be happy about moving tee(1) from
/usr/bin to /bin.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: more info Re: how did I manage this?

[Adrian Filipi-Martin]

On Sun, 12 Sep 1999, Chris Costello wrote:

> On Sun, Sep 12, 1999, Wayne Cuddy wrote:
> > Here is my directory listing:
> > drwxrwxr-x  3 wcuddy  wcuddy   512 Sep  5 17:29 $DEST_DIR
> > -rwxr-xr-x  1 wcuddy  wcuddy  2324 Sep  6 22:51 do_install.sh
> > -rw-rw-r--  1 wcuddy  wcuddy   533 Sep  5 21:12 file_list.txt
> > -rw-rw-r--  1 wcuddy  wcuddy   155 Sep  5 21:58 install.conf
> > -rw-rw-r--  1 wcuddy  wcuddy   145 Sep  6 22:27 post-install
> > -rw-rw-r--  1 wcuddy  wcuddy   144 Sep  6 22:24 pre-install
> > 
> > Here is the output of my mount:
> > /dev/da0s1a on / (asynchronous, NFS exported, local, writes: sync 26 async
> > 22259)
> > /dev/da2s1e on /home (asynchronous, local, writes: sync 8 async 5181)
> > /dev/da1s1e on /usr (asynchronous, local, writes: sync 3 async 20654)
> > procfs on /proc (local)
> > 
> > Since /home is on a separate file system I don't think it is a hard link.
> > However, if do a 'cd \$DEST_DIR' I end up in the root directory.  If I do a
> > 'rm $DEST_DIR/', I get 'rm: /: is a directory'.  If it can't be a hard link I
> > have no idea what it is.

[This is actually  aresponse to two messages.  Sorry, but I didn't
 want to repeat myself. ]

The root inode number of any filesystem is '2'.  I forget why, but
that's the way it is. 

Now, first I doubt the above is a hard link to / because the
ownership is in the inode and unless you tell me that / is owned by
wcuddy:wcuddy, it cannot be linked to the same inode. 

What does 'pwd' and 'df .' give you back as your current directory
and physical device?  You alos ought to include the '-i' in the ls command
because it will add the inode number to the listing.

Try 'ls -l '$DEST_DIR/kernel'".  Unless you get the same output as
"ls -l /kernel", you probably just have a bad directory name.

If you really have a a directory with a link count of three, it
ought to be a directory with exactly one subdirectory.  Given that root has
a bunch of subdirectories, a link count more like the 20 shown above is
typical.

After reading your other messages, I think you have a "wierdly" 
named directory with another "wierdly" named directory in it.  In
particular both have $'s in their names.  I bet it looks somehting like the
following.  Note the link count for '$DEST_DIR' is 3 as in your listing
above. 

> : ubergeek@terrafirma; mkdir -p \$DEST_DIR/\$2
> : ubergeek@terrafirma; ls -laRi
> total 3
> 6020 drwxrwxr-x  3 ubergeek  wheel  512 Sep 12 14:21 $DEST_DIR/
> 6018 drwxrwxr-x  3 ubergeek  wheel  512 Sep 12 14:21 ./
>2 drwxrwxrwt  6 root  wheel  512 Sep 12 14:12 ../
> 
> ./$DEST_DIR:
> total 3
> 6026 drwxrwxr-x  2 ubergeek  wheel  512 Sep 12 14:21 $2/
> 6020 drwxrwxr-x  3 ubergeek  wheel  512 Sep 12 14:21 ./
> 6018 drwxrwxr-x  3 ubergeek  wheel  512 Sep 12 14:21 ../
> 
> ./$DEST_DIR/$2:
> total 2
> 6026 drwxrwxr-x  2 ubergeek  wheel  512 Sep 12 14:21 ./
> 6020 drwxrwxr-x  3 ubergeek  wheel  512 Sep 12 14:21 ../

Now your shell is probably causing you the problems.  Make sure you
are properly quoting the paths.  single and double quotes make a big
difference here.

> : ubergeek@terrafirma; \ls -ild '$DEST_DIR/$2'
> 6026 drwxrwxr-x  2 ubergeek  wheel  512 Sep 12 14:21 $DEST_DIR/$2
> : ubergeek@terrafirma; \ls -lid "$DEST_DIR/$2"
> 2 drwxr-xr-x  20 root  wheel  512 Aug  7 16:28 /

Notice the last line.  This is probably what is happening.  Try 'rm
-rfi *' and see if you can remove all these bad directory names and start
over.  e.g.

> : ubergeek@terrafirma; rm -rfi *
> remove $DEST_DIR? y
> remove $DEST_DIR/$2? y

If this thread is to continue, I suggest moving it to -questions,
because I'm pretty certain it's not an actual filesystem corruption issue.

cheers,

Adrian
--
[ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: more info Re: how did I manage this?

[Adrian Filipi-Martin]

On Sun, 12 Sep 1999, Chris Costello wrote:

> On Sun, Sep 12, 1999, Wayne Cuddy wrote:
> > Here is my directory listing:
> > drwxrwxr-x  3 wcuddy  wcuddy   512 Sep  5 17:29 $DEST_DIR
> > -rwxr-xr-x  1 wcuddy  wcuddy  2324 Sep  6 22:51 do_install.sh
> > -rw-rw-r--  1 wcuddy  wcuddy   533 Sep  5 21:12 file_list.txt
> > -rw-rw-r--  1 wcuddy  wcuddy   155 Sep  5 21:58 install.conf
> > -rw-rw-r--  1 wcuddy  wcuddy   145 Sep  6 22:27 post-install
> > -rw-rw-r--  1 wcuddy  wcuddy   144 Sep  6 22:24 pre-install
> > 
> > Here is the output of my mount:
> > /dev/da0s1a on / (asynchronous, NFS exported, local, writes: sync 26 async
> > 22259)
> > /dev/da2s1e on /home (asynchronous, local, writes: sync 8 async 5181)
> > /dev/da1s1e on /usr (asynchronous, local, writes: sync 3 async 20654)
> > procfs on /proc (local)
> > 
> > Since /home is on a separate file system I don't think it is a hard link.
> > However, if do a 'cd \$DEST_DIR' I end up in the root directory.  If I do a
> > 'rm $DEST_DIR/', I get 'rm: /: is a directory'.  If it can't be a hard link 
> > I
> > have no idea what it is.

[This is actually  aresponse to two messages.  Sorry, but I didn't
 want to repeat myself. ]

The root inode number of any filesystem is '2'.  I forget why, but
that's the way it is. 

Now, first I doubt the above is a hard link to / because the
ownership is in the inode and unless you tell me that / is owned by
wcuddy:wcuddy, it cannot be linked to the same inode. 

What does 'pwd' and 'df .' give you back as your current directory
and physical device?  You alos ought to include the '-i' in the ls command
because it will add the inode number to the listing.

Try 'ls -l '$DEST_DIR/kernel'".  Unless you get the same output as
"ls -l /kernel", you probably just have a bad directory name.

If you really have a a directory with a link count of three, it
ought to be a directory with exactly one subdirectory.  Given that root has
a bunch of subdirectories, a link count more like the 20 shown above is
typical.

After reading your other messages, I think you have a "wierdly" 
named directory with another "wierdly" named directory in it.  In
particular both have $'s in their names.  I bet it looks somehting like the
following.  Note the link count for '$DEST_DIR' is 3 as in your listing
above. 

> : uberg...@terrafirma; mkdir -p \$DEST_DIR/\$2
> : uberg...@terrafirma; ls -laRi
> total 3
> 6020 drwxrwxr-x  3 ubergeek  wheel  512 Sep 12 14:21 $DEST_DIR/
> 6018 drwxrwxr-x  3 ubergeek  wheel  512 Sep 12 14:21 ./
>2 drwxrwxrwt  6 root  wheel  512 Sep 12 14:12 ../
> 
> ./$DEST_DIR:
> total 3
> 6026 drwxrwxr-x  2 ubergeek  wheel  512 Sep 12 14:21 $2/
> 6020 drwxrwxr-x  3 ubergeek  wheel  512 Sep 12 14:21 ./
> 6018 drwxrwxr-x  3 ubergeek  wheel  512 Sep 12 14:21 ../
> 
> ./$DEST_DIR/$2:
> total 2
> 6026 drwxrwxr-x  2 ubergeek  wheel  512 Sep 12 14:21 ./
> 6020 drwxrwxr-x  3 ubergeek  wheel  512 Sep 12 14:21 ../

Now your shell is probably causing you the problems.  Make sure you
are properly quoting the paths.  single and double quotes make a big
difference here.

> : uberg...@terrafirma; \ls -ild '$DEST_DIR/$2'
> 6026 drwxrwxr-x  2 ubergeek  wheel  512 Sep 12 14:21 $DEST_DIR/$2
> : uberg...@terrafirma; \ls -lid "$DEST_DIR/$2"
> 2 drwxr-xr-x  20 root  wheel  512 Aug  7 16:28 /

Notice the last line.  This is probably what is happening.  Try 'rm
-rfi *' and see if you can remove all these bad directory names and start
over.  e.g.

> : uberg...@terrafirma; rm -rfi *
> remove $DEST_DIR? y
> remove $DEST_DIR/$2? y

If this thread is to continue, I suggest moving it to -questions,
because I'm pretty certain it's not an actual filesystem corruption issue.

cheers,

Adrian
--
[ adr...@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ]




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: more info Re: how did I manage this?

[Chris Costello]

On Sun, Sep 12, 1999, Wayne Cuddy wrote:
> >ls '$DEST_DIR'
> $2
> 
> Interestingly enough 2 is the inode number of both the root directory and the 
> root
> directory of the /home partition.

   That's not all too interesting.  It seems to be normal:

$ ls -ldi /usr / /var
2 drwxr-xr-x  20 root  wheel  1024 Aug 20 21:15 /
2 drwxr-xr-x  27 root  wheel   512 Sep  9 15:58 /usr
2 drwxr-xr-x  18 root  wheel   512 May 27 06:13 /var

-- 
|Chris Costello 
|Programming Department:  Mistakes made while you wait.
`--


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: more info Re: how did I manage this?

[Chris Costello]

On Sun, Sep 12, 1999, Wayne Cuddy wrote:
> >ls '$DEST_DIR'
> $2
> 
> Interestingly enough 2 is the inode number of both the root directory and the root
> directory of the /home partition.

   That's not all too interesting.  It seems to be normal:

$ ls -ldi /usr / /var
2 drwxr-xr-x  20 root  wheel  1024 Aug 20 21:15 /
2 drwxr-xr-x  27 root  wheel   512 Sep  9 15:58 /usr
2 drwxr-xr-x  18 root  wheel   512 May 27 06:13 /var

-- 
|Chris Costello <[EMAIL PROTECTED]>
|Programming Department:  Mistakes made while you wait.
`--


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: more info Re: how did I manage this?

[Wayne Cuddy]

On Sun, 12 Sep 1999, Chris Costello wrote:

> Date: Sun, 12 Sep 1999 10:13:45 -0500
> From: Chris Costello <[EMAIL PROTECTED]>
> To: Wayne Cuddy <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: more info Re: how did I manage this?
> 
> On Sun, Sep 12, 1999, Chris Costello wrote:
> > > However, if do a 'cd \$DEST_DIR' I end up in the root directory.  If I do a
> > > 'rm $DEST_DIR/', I get 'rm: /: is a directory'.  If it can't be a hard link I
> > > have no idea what it is.
> > 
> >That's because $DEST_DIR is expanding to "/".
> 
>Oops!  No it's not.  It's expanding to nothing because it's
> unset.  See my second paragraph (sentence):
> 
> >Try unsetting that variable and then enclosing it in single
> > quotes in your rm command.
> 
> -- 
> |Chris Costello <[EMAIL PROTECTED]>
> |A low level language is one whose programs
> |require attention to the irrelevant.
> `--
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 
It is not set but also it will not expand to nothing as I prefixed it with the
'\' character.  For instance if you do 'ls \$HOME' the ls command will look
for an entry of $HOME.  However I went ahead and tried the single quotes and
some more commands (output below):

>rm '$DEST_DIR'
rm: $DEST_DIR: is a directory

>ls '$DEST_DIR'
$2

Interestingly enough 2 is the inode number of both the root directory and the root
directory of the /home partition.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: more info Re: how did I manage this?

[Wayne Cuddy]

On Sun, 12 Sep 1999, Chris Costello wrote:

> Date: Sun, 12 Sep 1999 10:13:45 -0500
> From: Chris Costello 
> To: Wayne Cuddy 
> Cc: hack...@freebsd.org
> Subject: Re: more info Re: how did I manage this?
> 
> On Sun, Sep 12, 1999, Chris Costello wrote:
> > > However, if do a 'cd \$DEST_DIR' I end up in the root directory.  If I do 
> > > a
> > > 'rm $DEST_DIR/', I get 'rm: /: is a directory'.  If it can't be a hard 
> > > link I
> > > have no idea what it is.
> > 
> >That's because $DEST_DIR is expanding to "/".
> 
>Oops!  No it's not.  It's expanding to nothing because it's
> unset.  See my second paragraph (sentence):
> 
> >Try unsetting that variable and then enclosing it in single
> > quotes in your rm command.
> 
> -- 
> |Chris Costello 
> |A low level language is one whose programs
> |require attention to the irrelevant.
> `--
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 
It is not set but also it will not expand to nothing as I prefixed it with the
'\' character.  For instance if you do 'ls \$HOME' the ls command will look
for an entry of $HOME.  However I went ahead and tried the single quotes and
some more commands (output below):

>rm '$DEST_DIR'
rm: $DEST_DIR: is a directory

>ls '$DEST_DIR'
$2

Interestingly enough 2 is the inode number of both the root directory and the 
root
directory of the /home partition.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Ariel RS 2000 T1/EI card

[Jeroen Ruigrok/Asmodai]

[snip]

Please people. When posting messages DON'T reply to other messages
if the topic has NOTHING to do with the topic being discussed.

This obviously messes up reply-to headers, makes the archives less
useful as well and generally screws up threading in MUA's.

Thanks.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
...fools rush in where Daemons fear to tread.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Ariel RS 2000 T1/EI card

[Jeroen Ruigrok/Asmodai]

[snip]

Please people. When posting messages DON'T reply to other messages
if the topic has NOTHING to do with the topic being discussed.

This obviously messes up reply-to headers, makes the archives less
useful as well and generally screws up threading in MUA's.

Thanks.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
...fools rush in where Daemons fear to tread.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: more info Re: how did I manage this?

[Chris Costello]

On Sun, Sep 12, 1999, Chris Costello wrote:
> > However, if do a 'cd \$DEST_DIR' I end up in the root directory.  If I do a
> > 'rm $DEST_DIR/', I get 'rm: /: is a directory'.  If it can't be a hard link I
> > have no idea what it is.
> 
>That's because $DEST_DIR is expanding to "/".

   Oops!  No it's not.  It's expanding to nothing because it's
unset.  See my second paragraph (sentence):

>Try unsetting that variable and then enclosing it in single
> quotes in your rm command.

-- 
|Chris Costello <[EMAIL PROTECTED]>
|A low level language is one whose programs
|require attention to the irrelevant.
`--


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: more info Re: how did I manage this?

[Chris Costello]

On Sun, Sep 12, 1999, Chris Costello wrote:
> > However, if do a 'cd \$DEST_DIR' I end up in the root directory.  If I do a
> > 'rm $DEST_DIR/', I get 'rm: /: is a directory'.  If it can't be a hard link 
> > I
> > have no idea what it is.
> 
>That's because $DEST_DIR is expanding to "/".

   Oops!  No it's not.  It's expanding to nothing because it's
unset.  See my second paragraph (sentence):

>Try unsetting that variable and then enclosing it in single
> quotes in your rm command.

-- 
|Chris Costello 
|A low level language is one whose programs
|require attention to the irrelevant.
`--


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: more info Re: how did I manage this?

[Chris Costello]

On Sun, Sep 12, 1999, Wayne Cuddy wrote:
> Here is my directory listing:
> drwxrwxr-x  3 wcuddy  wcuddy   512 Sep  5 17:29 $DEST_DIR
> -rwxr-xr-x  1 wcuddy  wcuddy  2324 Sep  6 22:51 do_install.sh
> -rw-rw-r--  1 wcuddy  wcuddy   533 Sep  5 21:12 file_list.txt
> -rw-rw-r--  1 wcuddy  wcuddy   155 Sep  5 21:58 install.conf
> -rw-rw-r--  1 wcuddy  wcuddy   145 Sep  6 22:27 post-install
> -rw-rw-r--  1 wcuddy  wcuddy   144 Sep  6 22:24 pre-install
> 
> Here is the output of my mount:
> /dev/da0s1a on / (asynchronous, NFS exported, local, writes: sync 26 async
> 22259)
> /dev/da2s1e on /home (asynchronous, local, writes: sync 8 async 5181)
> /dev/da1s1e on /usr (asynchronous, local, writes: sync 3 async 20654)
> procfs on /proc (local)
> 
> Since /home is on a separate file system I don't think it is a hard link.
> However, if do a 'cd \$DEST_DIR' I end up in the root directory.  If I do a
> 'rm $DEST_DIR/', I get 'rm: /: is a directory'.  If it can't be a hard link I
> have no idea what it is.

   That's because $DEST_DIR is expanding to "/".

   Try unsetting that variable and then enclosing it in single
quotes in your rm command.

-- 
|Chris Costello <[EMAIL PROTECTED]>
|Managing programmers is like herding cats.
`--


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: more info Re: how did I manage this?

[Chris Costello]

On Sun, Sep 12, 1999, Wayne Cuddy wrote:
> Here is my directory listing:
> drwxrwxr-x  3 wcuddy  wcuddy   512 Sep  5 17:29 $DEST_DIR
> -rwxr-xr-x  1 wcuddy  wcuddy  2324 Sep  6 22:51 do_install.sh
> -rw-rw-r--  1 wcuddy  wcuddy   533 Sep  5 21:12 file_list.txt
> -rw-rw-r--  1 wcuddy  wcuddy   155 Sep  5 21:58 install.conf
> -rw-rw-r--  1 wcuddy  wcuddy   145 Sep  6 22:27 post-install
> -rw-rw-r--  1 wcuddy  wcuddy   144 Sep  6 22:24 pre-install
> 
> Here is the output of my mount:
> /dev/da0s1a on / (asynchronous, NFS exported, local, writes: sync 26 async
> 22259)
> /dev/da2s1e on /home (asynchronous, local, writes: sync 8 async 5181)
> /dev/da1s1e on /usr (asynchronous, local, writes: sync 3 async 20654)
> procfs on /proc (local)
> 
> Since /home is on a separate file system I don't think it is a hard link.
> However, if do a 'cd \$DEST_DIR' I end up in the root directory.  If I do a
> 'rm $DEST_DIR/', I get 'rm: /: is a directory'.  If it can't be a hard link I
> have no idea what it is.

   That's because $DEST_DIR is expanding to "/".

   Try unsetting that variable and then enclosing it in single
quotes in your rm command.

-- 
|Chris Costello 
|Managing programmers is like herding cats.
`--


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

more info Re: how did I manage this?

[Wayne Cuddy]

On Sat, 11 Sep 1999, Chris Costello wrote:

> Date: Sat, 11 Sep 1999 16:04:25 -0500
> From: Chris Costello <[EMAIL PROTECTED]>
> To: Wayne Cuddy <[EMAIL PROTECTED]>
> Cc: FreeBSD Hackers List <[EMAIL PROTECTED]>
> Subject: Re: how did I manage this? (fwd)
> 
> On Sat, Sep 11, 1999, Wayne Cuddy wrote:
> > I tried this on questions with no response and wanted give you guys a shot.
> 
> ls -li /path/to/your/alleged/hardlink
> ls -li /
> 
>Are the inode numbers the same?
> 
> > Thanks,
> > Wayne
> 
> -- 
> |Chris Costello <[EMAIL PROTECTED]>
> |In the field of observation, chance favors only the prepared minds.
> `---
>
Here is my directory listing:
drwxrwxr-x  3 wcuddy  wcuddy   512 Sep  5 17:29 $DEST_DIR
-rwxr-xr-x  1 wcuddy  wcuddy  2324 Sep  6 22:51 do_install.sh
-rw-rw-r--  1 wcuddy  wcuddy   533 Sep  5 21:12 file_list.txt
-rw-rw-r--  1 wcuddy  wcuddy   155 Sep  5 21:58 install.conf
-rw-rw-r--  1 wcuddy  wcuddy   145 Sep  6 22:27 post-install
-rw-rw-r--  1 wcuddy  wcuddy   144 Sep  6 22:24 pre-install

Here is the output of my mount:
/dev/da0s1a on / (asynchronous, NFS exported, local, writes: sync 26 async
22259)
/dev/da2s1e on /home (asynchronous, local, writes: sync 8 async 5181)
/dev/da1s1e on /usr (asynchronous, local, writes: sync 3 async 20654)
procfs on /proc (local)

Since /home is on a separate file system I don't think it is a hard link.
However, if do a 'cd \$DEST_DIR' I end up in the root directory.  If I do a
'rm $DEST_DIR/', I get 'rm: /: is a directory'.  If it can't be a hard link I
have no idea what it is.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

more info Re: how did I manage this?

[Wayne Cuddy]

On Sat, 11 Sep 1999, Chris Costello wrote:

> Date: Sat, 11 Sep 1999 16:04:25 -0500
> From: Chris Costello 
> To: Wayne Cuddy 
> Cc: FreeBSD Hackers List 
> Subject: Re: how did I manage this? (fwd)
> 
> On Sat, Sep 11, 1999, Wayne Cuddy wrote:
> > I tried this on questions with no response and wanted give you guys a shot.
> 
> ls -li /path/to/your/alleged/hardlink
> ls -li /
> 
>Are the inode numbers the same?
> 
> > Thanks,
> > Wayne
> 
> -- 
> |Chris Costello 
> |In the field of observation, chance favors only the prepared minds.
> `---
>
Here is my directory listing:
drwxrwxr-x  3 wcuddy  wcuddy   512 Sep  5 17:29 $DEST_DIR
-rwxr-xr-x  1 wcuddy  wcuddy  2324 Sep  6 22:51 do_install.sh
-rw-rw-r--  1 wcuddy  wcuddy   533 Sep  5 21:12 file_list.txt
-rw-rw-r--  1 wcuddy  wcuddy   155 Sep  5 21:58 install.conf
-rw-rw-r--  1 wcuddy  wcuddy   145 Sep  6 22:27 post-install
-rw-rw-r--  1 wcuddy  wcuddy   144 Sep  6 22:24 pre-install

Here is the output of my mount:
/dev/da0s1a on / (asynchronous, NFS exported, local, writes: sync 26 async
22259)
/dev/da2s1e on /home (asynchronous, local, writes: sync 8 async 5181)
/dev/da1s1e on /usr (asynchronous, local, writes: sync 3 async 20654)
procfs on /proc (local)

Since /home is on a separate file system I don't think it is a hard link.
However, if do a 'cd \$DEST_DIR' I end up in the root directory.  If I do a
'rm $DEST_DIR/', I get 'rm: /: is a directory'.  If it can't be a hard link I
have no idea what it is.




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Ariel RS 2000 T1/EI card

[Len Conrad]

A few weeks ago...

R Cramer <[EMAIL PROTECTED]> and Niall Smart <[EMAIL PROTECTED]>

told me they were working on, or wanted to work on, a RAS server using the 
2000. Now, neither one responds to several mails.

Anybody know of anybody ELSE looking at this card or how else to contact 
these guys?

tia,
Len





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Ariel RS 2000 T1/EI card

[Len Conrad]

A few weeks ago...

R Cramer  and Niall Smart 

told me they were working on, or wanted to work on, a RAS server using the 
2000. Now, neither one responds to several mails.


Anybody know of anybody ELSE looking at this card or how else to contact 
these guys?


tia,
Len





To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to go about making a compiler port

[Kim Shrier]

The Objective C port in lang/objc has the same problem.  The Makefile
detects if there is an Objective C compiler and if not, it downloads
a bootstrap version of the compiler as C source and builds that first.
It then uses the bootstrap compiler to build the Objective C compiler
and support libraries.  This way, you don't have to add a
"make bootstrap" step.

Kim Shrier
-- 
 Kim Shrier - principal, Shrier and Deihl - mailto:[EMAIL PROTECTED]
Remote Unix Network Admin, Security, Internet Software Development
  Tinker Internet Services - Superior FreeBSD-based Web Hosting
 http://www.tinker.com/

Simon Marlow wrote:
> 
> [originally sent to ports, resending to hackers at the suggestion of someone
> on that list.]
> 
> Hi Folks,
> 
> I'd like to make a port for our Haskell compiler, GHC (see
> http://research.microsoft.com/users/t-simonm/ghc).  There are some subtle
> problems with this:
> 
> - GHC depends on itself.  That is, you need GHC
>   installed in order to build GHC.
> 
> - GHC depends on Happy, our parser generator.
> 
> - Happy depends on GHC (it's written in Haskell).
> 
> So, one solution would be to provide a binary port, say ghc-bin, which would
> install a binary distribution.  I checked the modula-3 port, and it doesn't
> seem to have a binary port, so what's the accepted way of doing this?
> 
> It's possible to bootstrap GHC from intermediate C files, but it's a bit
> fiddly and I'd prefer not to do this if possible.  However, one thing that
> occurs to me is that the port could bootstrap itself from C if you say 'make
> BOOTSTRAP=YES', and otherwise attempt to build using an installed GHC.
> 
> Any thoughts greatly appreciated.
> 
> I'm not on this list, BTW.
> 
> Cheers,
> Simon
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to go about making a compiler port

[Kim Shrier]

The Objective C port in lang/objc has the same problem.  The Makefile
detects if there is an Objective C compiler and if not, it downloads
a bootstrap version of the compiler as C source and builds that first.
It then uses the bootstrap compiler to build the Objective C compiler
and support libraries.  This way, you don't have to add a
"make bootstrap" step.

Kim Shrier
-- 
 Kim Shrier - principal, Shrier and Deihl - mailto:k...@tinker.com
Remote Unix Network Admin, Security, Internet Software Development
  Tinker Internet Services - Superior FreeBSD-based Web Hosting
 http://www.tinker.com/

Simon Marlow wrote:
> 
> [originally sent to ports, resending to hackers at the suggestion of someone
> on that list.]
> 
> Hi Folks,
> 
> I'd like to make a port for our Haskell compiler, GHC (see
> http://research.microsoft.com/users/t-simonm/ghc).  There are some subtle
> problems with this:
> 
> - GHC depends on itself.  That is, you need GHC
>   installed in order to build GHC.
> 
> - GHC depends on Happy, our parser generator.
> 
> - Happy depends on GHC (it's written in Haskell).
> 
> So, one solution would be to provide a binary port, say ghc-bin, which would
> install a binary distribution.  I checked the modula-3 port, and it doesn't
> seem to have a binary port, so what's the accepted way of doing this?
> 
> It's possible to bootstrap GHC from intermediate C files, but it's a bit
> fiddly and I'd prefer not to do this if possible.  However, one thing that
> occurs to me is that the port could bootstrap itself from C if you say 'make
> BOOTSTRAP=YES', and otherwise attempt to build using an installed GHC.
> 
> Any thoughts greatly appreciated.
> 
> I'm not on this list, BTW.
> 
> Cheers,
> Simon
>


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: CS Project

[Dag-Erling Smorgrav]

Chris Costello  writes:
> On Thu, Sep 09, 1999, Narvi wrote:
> > It sounds like a "FreeBSD VM", VM taken to mean virtual machine. Anybody
> > in such a 'jar' would not notice (be able to notice) the existence of
> > others at all. 
>In Texas we call that a chroot.

ITYM jail(2), which is only available in -CURRENT.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: CS Project

[Dag-Erling Smorgrav]

Chris Costello <[EMAIL PROTECTED]> writes:
> On Thu, Sep 09, 1999, Narvi wrote:
> > It sounds like a "FreeBSD VM", VM taken to mean virtual machine. Anybody
> > in such a 'jar' would not notice (be able to notice) the existence of
> > others at all. 
>In Texas we call that a chroot.

ITYM jail(2), which is only available in -CURRENT.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: More press

[Dag-Erling Smorgrav]

Dirk GOUDERS  writes:
> Oh, sorry -- my "browse-url-at-mouse" function made
> 
> http://www.zdnet.com/zdtv/screensavers/answerstips/story/02c36562c23246242c00.html
> 
> of it...

Netscape uses commans to separate parameters to the OpenURL command.
Fortunately, the API is open and documented, so there's nothing to
stop someone from writing a small command-line util that does the
equivalent of "netscape -remote" except faster and better.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: More press

[Dag-Erling Smorgrav]

Dirk GOUDERS <[EMAIL PROTECTED]> writes:
> Oh, sorry -- my "browse-url-at-mouse" function made
> 
> http://www.zdnet.com/zdtv/screensavers/answerstips/story/02c36562c23246242c00.html
> 
> of it...

Netscape uses commans to separate parameters to the OpenURL command.
Fortunately, the API is open and documented, so there's nothing to
stop someone from writing a small command-line util that does the
equivalent of "netscape -remote" except faster and better.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to go about making a compiler port

[Jeroen Ruigrok/Asmodai]

* Simon Marlow ([EMAIL PROTECTED]) [990912 13:05]:

>I'd like to make a port for our Haskell compiler, GHC (see
>http://research.microsoft.com/users/t-simonm/ghc).  There are some subtle
>problems with this:
>
>   - GHC depends on itself.  That is, you need GHC
> installed in order to build GHC.
>   - GHC depends on Happy, our parser generator.
>   - Happy depends on GHC (it's written in Haskell).

>So, one solution would be to provide a binary port, say ghc-bin, which would
>install a binary distribution.  I checked the modula-3 port, and it doesn't
>seem to have a binary port, so what's the accepted way of doing this?

Well, you could also take a peek at net/cvsup-bin
Another binary used a lot. It might give some ideas.

>It's possible to bootstrap GHC from intermediate C files, but it's a bit
>fiddly and I'd prefer not to do this if possible.  However, one thing that
>occurs to me is that the port could bootstrap itself from C if you say 'make
>BOOTSTRAP=YES', and otherwise attempt to build using an installed GHC.

*nod*
That could be a solution. Although it requires a clue.
Normally one does:
make
make install
make clean

What could be a solution would be to make and after the make go
interactive and ask to try to bootstrap from C or use the GHC-binary.
print/apsfilter is a good example of interactive stuff...

>Any thoughts greatly appreciated.

These are just some random thoughts. Surely I am missing some pitfalls,
but these might spark some ideas.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
If I am telling you the Truth now, do you believe it?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to go about making a compiler port

[Jeroen Ruigrok/Asmodai]

* Simon Marlow (simon...@microsoft.com) [990912 13:05]:

>I'd like to make a port for our Haskell compiler, GHC (see
>http://research.microsoft.com/users/t-simonm/ghc).  There are some subtle
>problems with this:
>
>   - GHC depends on itself.  That is, you need GHC
> installed in order to build GHC.
>   - GHC depends on Happy, our parser generator.
>   - Happy depends on GHC (it's written in Haskell).

>So, one solution would be to provide a binary port, say ghc-bin, which would
>install a binary distribution.  I checked the modula-3 port, and it doesn't
>seem to have a binary port, so what's the accepted way of doing this?

Well, you could also take a peek at net/cvsup-bin
Another binary used a lot. It might give some ideas.

>It's possible to bootstrap GHC from intermediate C files, but it's a bit
>fiddly and I'd prefer not to do this if possible.  However, one thing that
>occurs to me is that the port could bootstrap itself from C if you say 'make
>BOOTSTRAP=YES', and otherwise attempt to build using an installed GHC.

*nod*
That could be a solution. Although it requires a clue.
Normally one does:
make
make install
make clean

What could be a solution would be to make and after the make go
interactive and ask to try to bootstrap from C or use the GHC-binary.
print/apsfilter is a good example of interactive stuff...

>Any thoughts greatly appreciated.

These are just some random thoughts. Surely I am missing some pitfalls,
but these might spark some ideas.

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
If I am telling you the Truth now, do you believe it?


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: More press

[Dirk GOUDERS]

 > > 
 > >  > There is a short but sweet[1] article on ZDNet today regarding FreeBSD:
 > >  >
 > >  > http://www.zdnet.com/zdtv/screensavers/answerstips/story/0,3656,2324624,00.html
 > > 
 > > Hmm, can't find that sweet thing -- typo?
 > 
 > Nope, it worked fine for me.  Given how short it is, this article really packs
 > a POSITIVE punch for FreeBSD.  Here's the text:
 > 
 > *SNIP*

Oh, sorry -- my "browse-url-at-mouse" function made

http://www.zdnet.com/zdtv/screensavers/answerstips/story/02c36562c23246242c00.html

of it...

Anyway, thanks for the text :-)

Dirk


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: More press

[Dirk GOUDERS]

 > > 
 > >  > There is a short but sweet[1] article on ZDNet today regarding FreeBSD:
 > >  >
 > >  > 
 > > http://www.zdnet.com/zdtv/screensavers/answerstips/story/0,3656,2324624,00.html
 > > 
 > > Hmm, can't find that sweet thing -- typo?
 > 
 > Nope, it worked fine for me.  Given how short it is, this article really 
 > packs
 > a POSITIVE punch for FreeBSD.  Here's the text:
 > 
 > *SNIP*

Oh, sorry -- my "browse-url-at-mouse" function made

http://www.zdnet.com/zdtv/screensavers/answerstips/story/02c36562c23246242c00.html

of it...

Anyway, thanks for the text :-)

Dirk


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to go about making a compiler port

[Satoshi - Ports Wraith - Asami]

 * From: Simon Marlow <[EMAIL PROTECTED]>

 * [originally sent to ports, resending to hackers at the suggestion of someone
 * on that list.]

Sorry, you probably caught us at the busiest time right before the
release

 * Hi Folks,
 * 
 * I'd like to make a port for our Haskell compiler, GHC (see
 * http://research.microsoft.com/users/t-simonm/ghc).  There are some subtle
 * problems with this:
 * 
 *  - GHC depends on itself.  That is, you need GHC
 *installed in order to build GHC.
 * 
 *  - GHC depends on Happy, our parser generator.
 *  
 *  - Happy depends on GHC (it's written in Haskell).
 * 
 * So, one solution would be to provide a binary port, say ghc-bin, which would
 * install a binary distribution.  I checked the modula-3 port, and it doesn't
 * seem to have a binary port, so what's the accepted way of doing this?

Look at lang/gnat.  It has a similar situation.

Satoshi


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to go about making a compiler port

[Satoshi - Ports Wraith - Asami]

 * From: Simon Marlow 

 * [originally sent to ports, resending to hackers at the suggestion of someone
 * on that list.]

Sorry, you probably caught us at the busiest time right before the
release

 * Hi Folks,
 * 
 * I'd like to make a port for our Haskell compiler, GHC (see
 * http://research.microsoft.com/users/t-simonm/ghc).  There are some subtle
 * problems with this:
 * 
 *  - GHC depends on itself.  That is, you need GHC
 *installed in order to build GHC.
 * 
 *  - GHC depends on Happy, our parser generator.
 *  
 *  - Happy depends on GHC (it's written in Haskell).
 * 
 * So, one solution would be to provide a binary port, say ghc-bin, which would
 * install a binary distribution.  I checked the modula-3 port, and it doesn't
 * seem to have a binary port, so what's the accepted way of doing this?

Look at lang/gnat.  It has a similar situation.

Satoshi


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to go about making a compiler port

[Nick Hibma]

What about providing a package (binary only distribution) and a port?
And the port could include the possibility to bootstrap the
installation.

See the handbook on how to build a package.

Nick


On Sun, 12 Sep 1999, Simon Marlow wrote:

> [originally sent to ports, resending to hackers at the suggestion of someone
> on that list.]
> 
> Hi Folks,
> 
> I'd like to make a port for our Haskell compiler, GHC (see
> http://research.microsoft.com/users/t-simonm/ghc).  There are some subtle
> problems with this:
> 
>   - GHC depends on itself.  That is, you need GHC
> installed in order to build GHC.
> 
>   - GHC depends on Happy, our parser generator.
>   
>   - Happy depends on GHC (it's written in Haskell).
> 
> So, one solution would be to provide a binary port, say ghc-bin, which would
> install a binary distribution.  I checked the modula-3 port, and it doesn't
> seem to have a binary port, so what's the accepted way of doing this?
> 
> It's possible to bootstrap GHC from intermediate C files, but it's a bit
> fiddly and I'd prefer not to do this if possible.  However, one thing that
> occurs to me is that the port could bootstrap itself from C if you say 'make
> BOOTSTRAP=YES', and otherwise attempt to build using an installed GHC.
> 
> Any thoughts greatly appreciated.
> 
> I'm not on this list, BTW.
> 
> Cheers,
>   Simon
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 
> 

-- 
e-Mail: [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: How to go about making a compiler port

[Nick Hibma]

What about providing a package (binary only distribution) and a port?
And the port could include the possibility to bootstrap the
installation.

See the handbook on how to build a package.

Nick


On Sun, 12 Sep 1999, Simon Marlow wrote:

> [originally sent to ports, resending to hackers at the suggestion of someone
> on that list.]
> 
> Hi Folks,
> 
> I'd like to make a port for our Haskell compiler, GHC (see
> http://research.microsoft.com/users/t-simonm/ghc).  There are some subtle
> problems with this:
> 
>   - GHC depends on itself.  That is, you need GHC
> installed in order to build GHC.
> 
>   - GHC depends on Happy, our parser generator.
>   
>   - Happy depends on GHC (it's written in Haskell).
> 
> So, one solution would be to provide a binary port, say ghc-bin, which would
> install a binary distribution.  I checked the modula-3 port, and it doesn't
> seem to have a binary port, so what's the accepted way of doing this?
> 
> It's possible to bootstrap GHC from intermediate C files, but it's a bit
> fiddly and I'd prefer not to do this if possible.  However, one thing that
> occurs to me is that the port could bootstrap itself from C if you say 'make
> BOOTSTRAP=YES', and otherwise attempt to build using an installed GHC.
> 
> Any thoughts greatly appreciated.
> 
> I'm not on this list, BTW.
> 
> Cheers,
>   Simon
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 
> 

-- 
e-Mail: hi...@skylink.it



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

How to go about making a compiler port

[Simon Marlow]

[originally sent to ports, resending to hackers at the suggestion of someone
on that list.]

Hi Folks,

I'd like to make a port for our Haskell compiler, GHC (see
http://research.microsoft.com/users/t-simonm/ghc).  There are some subtle
problems with this:

- GHC depends on itself.  That is, you need GHC
  installed in order to build GHC.

- GHC depends on Happy, our parser generator.

- Happy depends on GHC (it's written in Haskell).

So, one solution would be to provide a binary port, say ghc-bin, which would
install a binary distribution.  I checked the modula-3 port, and it doesn't
seem to have a binary port, so what's the accepted way of doing this?

It's possible to bootstrap GHC from intermediate C files, but it's a bit
fiddly and I'd prefer not to do this if possible.  However, one thing that
occurs to me is that the port could bootstrap itself from C if you say 'make
BOOTSTRAP=YES', and otherwise attempt to build using an installed GHC.

Any thoughts greatly appreciated.

I'm not on this list, BTW.

Cheers,
Simon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

How to go about making a compiler port

[Simon Marlow]

[originally sent to ports, resending to hackers at the suggestion of someone
on that list.]

Hi Folks,

I'd like to make a port for our Haskell compiler, GHC (see
http://research.microsoft.com/users/t-simonm/ghc).  There are some subtle
problems with this:

- GHC depends on itself.  That is, you need GHC
  installed in order to build GHC.

- GHC depends on Happy, our parser generator.

- Happy depends on GHC (it's written in Haskell).

So, one solution would be to provide a binary port, say ghc-bin, which would
install a binary distribution.  I checked the modula-3 port, and it doesn't
seem to have a binary port, so what's the accepted way of doing this?

It's possible to bootstrap GHC from intermediate C files, but it's a bit
fiddly and I'd prefer not to do this if possible.  However, one thing that
occurs to me is that the port could bootstrap itself from C if you say 'make
BOOTSTRAP=YES', and otherwise attempt to build using an installed GHC.

Any thoughts greatly appreciated.

I'm not on this list, BTW.

Cheers,
Simon


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: damn ATX power supplies...

[Mike Nowlin]

> Yeah, you're supposed to tie PE low when you want power... However, in a
> system I'm working with now, we've discovered that some inexpensive ATX
> power supplies don't expect to have PE come up immediately when they're
> given power. If you see the symptom that all the LED's on your system dim
> about 1-2 seconds after you give the power supply AC for a second or so, you
> need to make a small timer circuit to wait 5 seconds or so before turning
> the PE line on.

Related info: if you have external devices (printer, and especially modem)
attached, try turning them off and then applying pwr to the computer.  In
some of the cheaper systems we have around here, the modem needs to be
turned off, or the computer flashes on for a second and then turns off...
(486 boards, AT power supplies)...  I did a bit of measuring, and on these
cheap ones, some of the +12V from the modem serial lines gets leaked back
into the power supply, causing it to wig out...

--mike




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: damn ATX power supplies...

[Mike Nowlin]

> Yeah, you're supposed to tie PE low when you want power... However, in a
> system I'm working with now, we've discovered that some inexpensive ATX
> power supplies don't expect to have PE come up immediately when they're
> given power. If you see the symptom that all the LED's on your system dim
> about 1-2 seconds after you give the power supply AC for a second or so, you
> need to make a small timer circuit to wait 5 seconds or so before turning
> the PE line on.

Related info: if you have external devices (printer, and especially modem)
attached, try turning them off and then applying pwr to the computer.  In
some of the cheaper systems we have around here, the modem needs to be
turned off, or the computer flashes on for a second and then turns off...
(486 boards, AT power supplies)...  I did a bit of measuring, and on these
cheap ones, some of the +12V from the modem serial lines gets leaked back
into the power supply, causing it to wig out...

--mike




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message