DragonFlyBSD

Michel Salim (via DragonFly issue tracker) wrote:

- My simplistic definition of getprogname() -- is it safe to just make it always
return "dma" ? Linux has no functional equivalent

No, you can't. dma can also act as "mailq", and should do so if called
with this name. It seems that glibc provides program_invocation_short_name.

- substituting sizeof([ph]->sa) for [ph]->sa.ss_len

I'm not sure if this works properly. I'll see what I can do.

Do let me know if there are any changes needed -- it'd be great to have DMA
working out-of-the-box on Linux. Also, are there any sample configuration files,
beyond the dma.8 documentation?

There is, but it is in the etc/ directory. I will move it.

How do you intend to work with reallocf and strlcpy? Should we include
that in the dma directory, or is there another way of doing it?

cheers
simon

Simon 'corecode' Schubert wrote:

Michel Salim (via DragonFly issue tracker) wrote:

- My simplistic definition of getprogname() -- is it safe to just make
it always
return "dma" ? Linux has no functional equivalent

No, you can't. dma can also act as "mailq", and should do so if called
with this name. It seems that glibc provides
program_invocation_short_name.

What about just taking argv⁰ early on?

Cheers,
--
Thomas E. Spanjaard
tgen@netphreax.net
tgen@deepbone.net

Thomas E. Spanjaard <tgen@netphreax.net> added the comment:

Simon 'corecode' Schubert wrote:

Michel Salim (via DragonFly issue tracker) wrote:

- My simplistic definition of getprogname() -- is it safe to just make
it always
return "dma" ? Linux has no functional equivalent

No, you can't. dma can also act as "mailq", and should do so if called
with this name. It seems that glibc provides
program_invocation_short_name.

What about just taking argv⁰ early on?

That would work too. So I should also install a symlink to mailq, then.

Simon 'corecode' Schubert <corecode@fs.ei.tum.de> added the comment:
How do you intend to work with reallocf and strlcpy? Should we include
that in the dma directory, or is there another way of doing it?

In the Makefile.linux, I currently just symlink the source file from
DragonFly's libc. Not sure what should be done -- those files are
really part of libc anyway. I'd say just leave them there. If dma
gets separated out into its own module, then provided the tarballs are
generated on a machine that has the full dfly git repo somewhere, just
script it so these two files get added to the archive.

Thanks,

--
Michel Alexandre Salim
Fedora Project

Shouldn't Makefile.linux be renamed to GNUmakefile so that GNU make(1) will pick
it up and prefer it over Makefile or BSDmakefile?

just food for thought

I forgot before to follow up: I've commited fixes to make dma compile on Linux.
Could you verify and confirm? You should be able to download a tarball from
<http://gitweb.dragonflybsd.org/dragonfly.git/snapshot/12b942762bf157d9b0596a00b57b01a719345322.tar.bz2>

Ulrich Spoerlein (via DragonFly issue tracker) wrote:

Shouldn't Makefile.linux be renamed to GNUmakefile so that GNU make(1) will pick
it up and prefer it over Makefile or BSDmakefile?

It is a generic makefile, good for any make. Also automating it too
much is of little use since the user has to specify some defines for
compilation.

cheers
simon