headers
Christopher Keeley | 1 Sep 2004 02:33

attaching a device

Hello all.

I have a question I hope somebody can shed some light on for me.

Im currently reading through OpenBSD system source code in the process
creating a hardware device driver for an x86 platform.

I am familiar with creating 'pseudo-device' driver(s) but would
like to write something hardware specific.

Am I correct in the knowledge that:

a)	in order for the kernel to
	execute the appropriate driver functions for a given block device driver,
	say, 'ide hard disk', it is necessary to create an instance of
	the 'cfattach' structure?

b)	I then proceed to add the relevant functions for the driver
	e.g attach, probe et al to the pointer(s) to function(s)
	in the 'cfattach' structure?.

c)	I need to create and initialise a 'cfdriver' structure?

I realise there are other thing to do, but I would like to know if
these are the necessary steps in order for the kernel to run the relevant
'attach' and 'probe' functions etc for a block device driver?

Its quite obvious that Im a n00b driver writer so forgive me if the
explanation
of what I am trying to achieve is somewhat lacking in relevant detail or
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ilya A. Kovalenko | 1 Sep 2004 10:25

Re: BUG on pf.conf parser

EA>   # this is a funky comment with a final slash and double line break \

EA>   pass in quick on lo0 proto tcp from any to 127.0.0.1 \
EA>              port ssh

EA>   Works perfectlly.

EA>   # this is a funky comment with a final slash and single line break \
EA>   pass in quick on lo0 proto tcp from any to 127.0.0.1 \
EA>          port ssh

it is feature, not a bug:
Henning Brauer> that is the correct behaviour. \ is the line continuation character...

so your construction treated as multiline comment

It just isn't documented on pf.conf(5) as well as should be.
Permalink | Reply | 0 comments |
headers
Bruno Rohee | 1 Sep 2004 12:09

Re: BUG on pf.conf parser

On Wed, Sep 01, 2004 at 09:27:18AM +0000, Thorsten Glaser wrote:
> >so your construction treated as multiline comment
> 
> This construct exists in the fewest languages.
> Most consider a comment line a comment line.

Well to take another example in the security field it is exactly the
same thing for tcpd in hosts.allow. See the thread given at the end
for a discussion on the same theme. It may be non-intuitive but
as long as it is documented...

http://www.security-express.com/archives/bugtraq/1999_2/0006.html

and its responses

--

-- 
It is impossible to experience one's death objectively and still carry
a tune.
		-- Woody Allen
Permalink | Reply | 0 comments |
headers
Ted Unangst | 2 Sep 2004 05:33

Re: attaching a device

On Wed, 1 Sep 2004, Christopher Keeley wrote:

> I am familiar with creating 'pseudo-device' driver(s) but would
> like to write something hardware specific.
> 
> Am I correct in the knowledge that:
> 
> a)	in order for the kernel to
> 	execute the appropriate driver functions for a given block device driver,
> 	say, 'ide hard disk', it is necessary to create an instance of
> 	the 'cfattach' structure?
> 
> b)	I then proceed to add the relevant functions for the driver
> 	e.g attach, probe et al to the pointer(s) to function(s)
> 	in the 'cfattach' structure?.
> 
> c)	I need to create and initialise a 'cfdriver' structure?

so far, i think this is all good and needed.

> I realise there are other thing to do, but I would like to know if
> these are the necessary steps in order for the kernel to run the relevant
> 'attach' and 'probe' functions etc for a block device driver?

make sure it's in config.  if you are creating a real block device, that 
lives under /dev/, you need to add it to arch/conf.c bdevsw.  also, create 
a char device, i don't think block only devices will work.

--

-- 
ask not what you can do for your country
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Espie | 3 Sep 2004 13:05
Favicon

autoconf speed-ups

Unless I'm mistaken, CONFIG_SITE can be used to prime any autoconf script
with a set of fixed values.

Compared to our older global cache, this looks much nicer: the global cache
had the issue that it was written to by each configure script, and thus you
had no real control about what got replaced there.

On the contrary, we can put the values we want and need in CONFIG_SITE,
and it looks like configure WON'T write to it at all...

I'm going to conduct some experiments with src and ports to see what
initial value we should start with, and how much we are likely to gain
from it. ;-)
Permalink | Reply | 0 comments |
headers
Brad Ely | 3 Sep 2004 21:36

dhclient-script unable to output messages (3.6 pre)

The dhclient-script tries to echo informational messages in a couple of
places, but they are currently going unseen.

$ grep echo /sbin/dhclient-script
		echo "search $new_domain_name" >>/etc/resolv.conf.std
			echo "nameserver $nameserver" >>/etc/resolv.conf.std
	echo "New Network Number: $new_network_number"
	echo "New Broadcast Address: $new_broadcast_address"

If I leave stdout open in fork_privchld, the messages appear again (but
still not in the daemon log file).

Index: dhclient.c
===================================================================
RCS file: /data2/obsd-cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.58
diff -u -r1.58 dhclient.c
--- dhclient.c	30 Aug 2004 07:43:32 -0000	1.58
+++ dhclient.c	3 Sep 2004 18:49:22 -0000
 <at>  <at>  -2351,7 +2351,7  <at>  <at> 
 	setproctitle("%s [priv]", ifi->name);

 	dup2(nullfd, STDIN_FILENO);
-	dup2(nullfd, STDOUT_FILENO);
+	/* dup2(nullfd, STDOUT_FILENO); */
 	dup2(nullfd, STDERR_FILENO);
 	close(nullfd);
 	close(fd2);

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thorsten Glaser | 3 Sep 2004 22:29
Picon

Re: system/3900: pppoe uses up too much CPU time (system)

Dixitur me scribere...

>Dixitur illum tedu <at> zeitbombe.org scribere...
>
>>i'd like anyone who uses pppoe to test this patch.  read the pr for more
>>details about the problem it corrects.  if you can test with 100
>>connections (esp. with before and after results), that'd be extra cool.

>Now pppoe(8) doesn't use 30-40% CPU on a loaded Pentium 120 system
>with >5 BitTorrents running, among other stuff, but only 1-2%.

After a few days, everyone on the box seems to have the
impression that _every_ connection (even if BT is idling or
just uploading (few conns)) is lagging way more than before.

Could be the patch, could it be not. Dunno.

bye,
//Thorsten
--

-- 
Currently blocking eMail from the following domains: bigpond.com, biz, gmx.de,
gmx.net, hotmail.com, info, jumpy.it, libero.it, name, netscape.net,
postino.it, simplesnet.pt, spymac.com, tatanova.com, tiscali.co.uk,
tiscali.cz, tiscali.de, tiscali.it, voila.fr, yahoo.co.uk, yahoo.com.
Permalink | Reply | 0 comments |
headers
Ray | 4 Sep 2004 10:01

mount -w patch during installation

Hi,
In response to
<https://marc.theaimsgroup.com/?l=openbsd-misc&m=109374144122248&w=2>,
here's a patch to always mount drives read-write during installation.
It's convenient, and I don't see a point in mounting a drive read-only
during installation.

-Ray-
Index: install.sub
===================================================================
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.350
diff -u -r1.350 install.sub
--- install.sub	25 Jul 2004 03:33:04 -0000	1.350
+++ install.sub	3 Sep 2004 07:04:25 -0000
 <at>  <at>  -1539,7 +1539,7  <at>  <at> 
 		[ "$_mp" = "/mnt" ] || mkdir -p $_mp

 		# Mount the filesystem. If the mount fails, exit.
-		if ! mount -v -t $_fstype $_async -o $_opt $_dev $_mp ; then
+		if ! mount -v -t $_fstype $_async -o $_opt -w $_dev $_mp ; then
 			# In addition to the error message displayed by mount ...
 			cat << __EOT
Permalink | Reply | 0 comments |
headers
Ray | 4 Sep 2004 20:46

Re: mount -w patch during installation

On Sat, Sep 04, 2004 at 10:24:14AM -0400, Kenneth R Westerback wrote:
> As the installation script says:
> 
> 'Non-ffs filesystems will be mounted read-only.'

Oops.  Okay, I was a bit hasty.

> First, the installation script is not supposed to touch such
> filesystems so safety dictates mounting them read-only. Second, some
> (such as NFS mounts or CDROM) might be created as read-only and
> complain or fail if read-write access is attempted.

As the installation script says:

`[drop] all filesystems which are nfs (since name resolution may
not be present).'

> Also, your change is incomplete as it should change/eliminate the
> code the reads the fstab and changes rw to ro for non-ffs
> filesystems. See install.sub around line 1514.

Noted.

> Finally, reading the referenced email, I see what you are attempting
> to fix and suggest you would be further ahead to submit a diff that
> alters the code around the install.sub line referenced above to
> change ro to rw for ffs filesystems.

Done and attached.
(Continue reading)

Permalink | Reply | 0 comments |
headers
J.C. Roberts | 7 Sep 2004 04:17

FreeBSD linprocfs and mount_linprocfs Porting?

Can anyone see a good reason to NOT port the FreeBSD linprocfs and
mount_linprocfs to OpenBSD?

There are troublesome executables which use information in the linux
/proc filesystem to figure out their own location. Current linux
emulation doesn't handle this properly since the readlink() call returns
info from the BSD /proc file system. In some of these cases, you can
build a simple wrapper for the executable in order to get it to work. 

i.e.
------------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

main()
{
  char buff[1024];
  sprintf(buff, "sudo mkdir /emul/linux/proc/%d", getpid());
  system(buff);
  sprintf(buff, "sudo ln -s /home/username/program/programname
/emul/linux/proc/%d/exe", getpid());

  system(buff);
  execlp("./programname", "./programname", NULL);
}
------------------------------------------------------------------

FreeBSD has a more complete solution to the Linux /proc filesystem
problems, so situations like the above can be solved with a simple
(Continue reading)

Permalink | Reply | 3 comments |

Gmane