Re: mixer applet.

2014-07-05 Thread bifferos


> On Saturday, 5 July 2014, 23:16, tito  wrote:
> > On Saturday 05 July 2014 20:32:18 bifferos wrote:
> scripts/bloat-o-meter busybox_old busybox_unstripped
> function                                             old     new   delta
> pr_level_exit                                         27       -     -27
> mixer_main                                           385     335     -50

I think the size I'm seeing must be something to do with the ancient cross 
compiler I'm using.

>     argc -= optind;

Dammit!  I was looking for optind but somehow missed it.  I suppose I was 
expecting opt_.  Will have to re-write my other applets to use it, 
thanks.

I'm just working on a 'button' applet for GPIO buttons, will finish that and 
come back to this one later.

/ # button
BusyBox v1.22.1 (2014-06-23 15:19:41 BST) multi-call binary.

Usage: button [-t ] [-F] BUTTON HELPER

Execute HELPER when button BUTTON is pressed

    -t N    Set the sampling period (debounce period, mS)
    -h  Exec when gpio goes high (default: low)
    -F  Run in foreground

HELPER receives the button number as argv[1], count as argv[2]


It's not really optimised yet, but I will incorporate suggestions from here.

bash-4.2$ ./scripts/bloat-o-meter busybox_before busybox_unstripped 
function old new   delta
button_main    - 659    +659
usage_messages 31150   31445    +295
button_shutdown    -  83 +83
applet_names 984 991  +7
applet_main  604 608  +4
applet_nameofs   302 304  +2
--
(add/remove: 3/0 grow/shrink: 4/0 up/down: 1050/0)   Total: 1050
bytes


regards,
Biff.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: mixer applet.

2014-07-05 Thread tito
On Saturday 05 July 2014 20:32:18 bifferos wrote:
> Here's a mixer applet (OSS).  It gets the list of mixer devices, gets and 
> sets individual device values.
> 
> 
> 
> / # mixer --help
> BusyBox v1.22.1 (2014-06-23 15:19:41 BST) multi-call binary.
> 
> Usage: mixer [-d DEVICE] [MIXER [LEVEL]]
> 
> Sets the mixer volume at a specific level (0-100)
> 
> -d DEVICEuse given mixer device (default /dev/mixer)
> 
> / # mixer
> Mixer: speaker mic phout
> 
> / # mixer speaker
> Level (L/R): 99/99
> 
> / # mixer speaker 20
> Level (L/R): 20/20
> 
> It adds about about 2.6k to Busybox and I don't really understand why.  Even 
> with the list of mixers it should only be ~500 bytes.
> If anyone has any suggestions I can try to fix that.
> 
> 
> regards,
> Biff.

Hi,
just for fun some size reduction. 
Tested it a little bit and it seems to work.

Ciao,
Tito

scripts/bloat-o-meter busybox_old busybox_unstripped
function old new   delta
pr_level_exit 27   - -27
mixer_main   385 335 -50
--
(add/remove: 0/1 grow/shrink: 0/1 up/down: 0/-77) Total: -77 bytes

int mixer_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE;
int mixer_main(int argc, char **argv)
{
int fd_mixer;
char* device = (char*)"/dev/mixer";
uint32_t level;
int devmask, n_dev;
const char *m_names[SOUND_MIXER_NRDEVICES] = SOUND_DEVICE_NAMES ;

/* option handling */
opt_complementary = "?2";  /* must have no more than 2 */
getopt32(argv, "d:", &device);
argc -= optind;
argv += optind;

fd_mixer = xopen(device, O_RDWR);
ioctl_or_perror_and_die(fd_mixer, SOUND_MIXER_READ_DEVMASK, &devmask, 
"DEVMASK");

switch (argc) {
case 2:
level = xatoi_range(argv[1], 1, 100);
break;
case 0:
printf("Mixer:");
}

/* mixer device enumeration */
for (n_dev = 0; n_dev < SOUND_MIXER_NRDEVICES; ++n_dev) {
if ((1 << n_dev) & devmask) {
if (*argv) {
if (strcmp(m_names[n_dev], *argv) == 0)
break;
} else {
printf(" %s", m_names[n_dev]);
}
}
}

if (!*argv) {
putchar('\n');
} else {
if (argc == 2) {
/* mixer device setting */
level = (level << 8) + level;
ioctl_or_perror_and_die(fd_mixer, MIXER_WRITE(n_dev), 
&level, "MIXER_WRITE");
} else {
/* mixer device reading */
ioctl_or_perror_and_die(fd_mixer, MIXER_READ(n_dev), 
&level, "MIXER_READ");
}
printf("Level (l/r): %d/%d\n", level & 0xff, ((level & 0xff00) 
>> 8));
}
return 0;
}
/* vi: set sw=4 ts=4: */
/*
 * Audio mixer for busybox (OSS emulation only)
 *
 * Copyright (c) Bifferos (sa...@bifferos.com)
 *
 * Licensed under GPLv2 or later, see file LICENSE in this source tree.
 *
 * Setting L/R stereo channels independently is unsupported in order to keep this applet small.
 *
 *
 */


#include 
#include "libbb.h"


//usage:#define mixer_trivial_usage
//usage:   "[-d DEVICE] [MIXER [LEVEL]]"
//usage:#define mixer_full_usage "\n\n"
//usage:   "Sets the mixer volume at a specific level (0-100)\n"
//usage:   "\n-d DEVICEuse given mixer device (default /dev/mixer)"
//usage:#define mixer_example_usage
//usage:   "# mixer vol 50\n"

int mixer_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE;
int mixer_main(int argc, char **argv)
{
	int fd_mixer;
	char* device = (char*)"/dev/mixer";
	uint32_t level;
	int devmask, n_dev;
	const char *m_names[SOUND_MIXER_NRDEVICES] = SOUND_DEVICE_NAMES ;

	/* option handling */
	opt_complementary = "?2";  /* must have no more than 2 */
	getopt32(argv, "d:", &device);
	argc -= optind;
	argv += optind;

	fd_mixer = xopen(device, O_RDWR);
	ioctl_or_perror_and_die(fd_mixer, SOUND_MIXER_READ_DEVMASK, &devmask, "DEVMASK");

	switch (argc) {
		case 2:
			level = xatoi_range(argv[1], 1, 100);
			break;
		case 0:
			printf("Mixer:");
	}

	/* mixer device enumeration */
	for (n_dev = 0; n_dev < SOUND_MIXER_NRDEVICES; ++n_dev) {
		if ((1 << n_dev) & devmask) {
			if (*argv) {
if (strcmp(m_names[n_dev], *argv) == 0)
	break;
			} else {
printf(" %s", m_names[n_dev]);
			}
		}
	}

	if (!*argv) {
		putchar('\n');
	} else {
		if (argc == 2) {
			/* mixer device setting */
			level = (level << 8) + level;
			ioctl_or_perror_and_die(fd_mixer, MIXER_WRITE(n_dev), &level, "MIXER_W

Re: mixer applet.

2014-07-05 Thread Isaac Dunham
On Sat, Jul 05, 2014 at 07:32:18PM +0100, bifferos wrote:
> Here's a mixer applet (OSS).  It gets the list of mixer devices, gets and 
> sets individual device values.

First, thanks! I'm interested, for one.

Second, it would be much easier to try out with the kconfig data included.
(A patch to add that to mixer.c is attached; apply with -p2 if you
don't have mixer.c in miscutils/)

Third, did you try checking size with "make bloatcheck"?
This shows the breakdown in how much is getting added by what functions/data.

On my current system (Alpine Linux, musl libc, GCC 4.8.2), I get this:
function old new   delta
mixer_main - 503+503
.rodata   135904  136174+270
packed_usage   29585   29663 +78
pr_level_exit  -  55 +55
applet_names24512457  +6
applet_main 14281432  +4
applet_nameofs   714 716  +2
--
(add/remove: 3/0 grow/shrink: 5/0 up/down: 918/0) Total: 918 bytes


> / # mixer --help
> BusyBox v1.22.1 (2014-06-23 15:19:41 BST) multi-call binary.
> 
> Usage: mixer [-d DEVICE] [MIXER [LEVEL]]
> 
> Sets the mixer volume at a specific level (0-100)
> 
>     -d DEVICE    use given mixer device (default /dev/mixer)
> 
> / # mixer
> Mixer: speaker mic phout
> 
> / # mixer speaker
> Level (L/R): 99/99
> 
> / # mixer speaker 20
> Level (L/R): 20/20
> 
> It adds about about 2.6k to Busybox and I don't really understand why.  Even 
> with the list of mixers it should only be ~500 bytes.  If anyone has any 
> suggestions I can try to fix that.

I'm seeing 918 bytes (gcc 4.8, musl libc).

It can be reduced at least 7 bytes from that, and perhaps 11 more to 900 bytes.

> regards,
> Biff.

> /* vi: set sw=4 ts=4: */
> /*
>  * Audio mixer for busybox (OSS emulation only)
>  *
>  * Copyright (c) Bifferos (sa...@bifferos.com)
>  *
>  * Licensed under GPLv2 or later, see file LICENSE in this source tree.
>  * 
>  * Setting L/R stereo channels independently is unsupported in order to keep 
> this applet small.
>  * 
>  *
>  */
> 
> 
> #include 
> #include "libbb.h"
> 

> //usage:#define mixer_trivial_usage
> //usage:   "[-d DEVICE] [MIXER [LEVEL]]"
> //usage:#define mixer_full_usage "\n\n"
> //usage:   "Sets the mixer volume at a specific level (0-100)\n"
> //usage:   "\n-d DEVICEuse given mixer device (default 
> /dev/mixer)"
> //usage:#define mixer_example_usage
> //usage:   "# mixer vol 50\n"
> 
Here, add: 
static void pr_level_exit(int level) NORETURN;

This will let you drop the "return 0;" at the end, and save ~3 bytes.
> static void pr_level_exit(int level)
> {
>   printf("Level (L/R): %d/%d\n", level&0xff, ((level&0xff00) >> 8));
>   exit(0);
> }
> 
> 
> int mixer_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE;
> int mixer_main(int argc, char **argv )
> {
>   int fd_mixer;
>   unsigned opts, extra_args;
>   char* device;
>   char* mixer = 0;
>   uint32_t write_level;
>   uint32_t read_level;
You only use read_level or write_level, and both are unconditionally
initialized when the code reaches them.
So you can change use "uint32_t level;" instead. (-4 bytes)
>   int devmask, i;
>   const char *m_names[SOUND_MIXER_NRDEVICES] = SOUND_DEVICE_NAMES ;
>   int mixer_device=0;
> 
> 
>   /* Option handling */
>   
>   opt_complementary = "?2";  /* must have no more than 2 */
>   opts = getopt32(argv, "d:", &device);
> 
>   extra_args = argc - 1;

I'm wondering why you don't do typical *argv++, argc--.
Is this smaller? 
>   if (opts & 1)
>   {
>   fd_mixer = xopen(device, O_RDWR);
>   extra_args -= 2;
>   }
>   else
>   {
>   fd_mixer = xopen("/dev/mixer", O_RDWR);
>   }
>   
>   if (extra_args) mixer = argv[argc - ((extra_args==1)?1:2)];

With argc and argv being manipulated, this is literally:
  if (argc--) mixer = argv[argc - (argc?0:1)];

But my understanding is that extra_args could not be larger than 2 here,
due to the previous line:
opt_complementary="?2";
Which suggests that you could do this:
  if (argc--) mixer = *argv;

or, if you want to keep extra_args, 
  if (extra_args) mixer = argv[argc - extra_args];

If this analysis is correct, the latter is 11 bytes saved.


> 
>   /* mixer device enumeration */
> 
>   ioctl_or_perror_and_die(fd_mixer, SOUND_MIXER_READ_DEVMASK, &devmask, 
> "DEVMASK");
>   
>   if (!mixer) printf("Mixer:");
> 
>   for (i = 0; i < SOUND_MIXER_NRDEVICES; ++i)
>   {
>   if ((1 << i) & devmask) {
>   if (mixer)
>   

mixer applet.

2014-07-05 Thread bifferos
Here's a mixer applet (OSS).  It gets the list of mixer devices, gets and sets 
individual device values.



/ # mixer --help
BusyBox v1.22.1 (2014-06-23 15:19:41 BST) multi-call binary.

Usage: mixer [-d DEVICE] [MIXER [LEVEL]]

Sets the mixer volume at a specific level (0-100)

    -d DEVICE    use given mixer device (default /dev/mixer)

/ # mixer
Mixer: speaker mic phout

/ # mixer speaker
Level (L/R): 99/99

/ # mixer speaker 20
Level (L/R): 20/20

It adds about about 2.6k to Busybox and I don't really understand why.  Even 
with the list of mixers it should only be ~500 bytes.  If anyone has any 
suggestions I can try to fix that.


regards,
Biff./* vi: set sw=4 ts=4: */
/*
 * Audio mixer for busybox (OSS emulation only)
 *
 * Copyright (c) Bifferos (sa...@bifferos.com)
 *
 * Licensed under GPLv2 or later, see file LICENSE in this source tree.
 * 
 * Setting L/R stereo channels independently is unsupported in order to keep this applet small.
 * 
 *
 */


#include 
#include "libbb.h"


//usage:#define mixer_trivial_usage
//usage:   "[-d DEVICE] [MIXER [LEVEL]]"
//usage:#define mixer_full_usage "\n\n"
//usage:   "Sets the mixer volume at a specific level (0-100)\n"
//usage:   "\n-d DEVICEuse given mixer device (default /dev/mixer)"
//usage:#define mixer_example_usage
//usage:   "# mixer vol 50\n"


static void pr_level_exit(int level)
{
	printf("Level (L/R): %d/%d\n", level&0xff, ((level&0xff00) >> 8));
	exit(0);
}


int mixer_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE;
int mixer_main(int argc, char **argv )
{
	int fd_mixer;
	unsigned opts, extra_args;
	char* device;
	char* mixer = 0;
	uint32_t write_level;
	uint32_t read_level;
	int devmask, i;
	const char *m_names[SOUND_MIXER_NRDEVICES] = SOUND_DEVICE_NAMES ;
	int mixer_device=0;


	/* Option handling */
	
	opt_complementary = "?2";  /* must have no more than 2 */
	opts = getopt32(argv, "d:", &device);

	extra_args = argc - 1;
	if (opts & 1)
	{
		fd_mixer = xopen(device, O_RDWR);
		extra_args -= 2;
	}
	else
	{
		fd_mixer = xopen("/dev/mixer", O_RDWR);
	}
	
	if (extra_args) mixer = argv[argc - ((extra_args==1)?1:2)];


	/* mixer device enumeration */

	ioctl_or_perror_and_die(fd_mixer, SOUND_MIXER_READ_DEVMASK, &devmask, "DEVMASK");
	
	if (!mixer) printf("Mixer:");

	for (i = 0; i < SOUND_MIXER_NRDEVICES; ++i)
	{
		if ((1 << i) & devmask) {
			if (mixer)
			{
if (strcmp(m_names[i], mixer) == 0) mixer_device = i;
			}
			else
			{
printf(" %s", m_names[i]);
			}
		}
	}

	if (!mixer)
	{
		printf("\n");
		exit(0);
	}


	/* mixer device reading */

	ioctl_or_perror_and_die(fd_mixer, MIXER_READ(mixer_device), &read_level, "MIXER_READ");

	if (extra_args == 1) pr_level_exit(read_level);


	/* mixer device setting */

	write_level = xatou_range(argv[argc - 1], 0, 100);
	write_level = (write_level<<8) + write_level;

	ioctl_or_perror_and_die(fd_mixer, MIXER_WRITE(mixer_device), &write_level, "MIXER_WRITE");

	pr_level_exit(write_level);
	

	return 0;
}
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] Use the standard libc types in fatattr

2014-07-05 Thread Laszlo Papp
On Sat, Jul 5, 2014 at 1:51 PM, Rich Felker  wrote:

> On Sat, Jul 05, 2014 at 12:20:51PM +0100, Laszlo Papp wrote:
> > > To be pedantic, uint32_t was introduced in the Open Group Base
> > > Specifications, Issue 5 (released in 1997, basis for UNIX98).
> > > At that point it was defined in , which only defined
> > > (u)int*_t.
> > >
> > > As far as when  was available, it was first shipped in
> glibc
> > > 2.1
> > > (and prereleases thereof), meaning it was first packaged in Debian 2.1
> > > (slink) on sparc.  Slink shipped with kernel 2.0.36.
> > > But the names of sized types in the kernel _could_ have been switched
> > > over when the standard was released, or rather during any of the
> "unstable"
> > > series after that; this is not a compiler change but a header change,
> > > and the kernel has its own headers. Kernel 2.0 was released in 1996
> > > (before the standard), but 2.2, 2.4, and 2.6 were released in 1999,
> > > 2001, and 2003.
> > >
> >
> > Glibc is not the only thing, in fact it has not been used much in
> embedded,
> > and even today, it is mostly for "computing embedded".
>
> From a header standpoint, uClibc effectively is (an old version of)
> glibc. From well after the standard types were added. So this is not
> an argument against using them.
>

I was not even referring to uClibc, eventually ...


>  > > The real reason is mentioned in the kernel coding style manual:
> > > some people don't like the "new" types.
> > >
> >
> > Tes... for good: "do not fix what is not broken".
>
> "Do not fix what is not broken" does not apply here. The kernel
> headers have ALWAYS been broken for use in userspace. The UAPI effort
> has partly fixed this (and is evidence that they _are_ trying to fix
> this, albeit poorly).
>

Just because you have a different personal style, it does not mean it is
broken. It has served and made Linux popular for well over a decade and a
half.

Again, I like the bikeshed pink.


>
> Rich
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] Use the standard libc types in fatattr

2014-07-05 Thread Rich Felker
On Sat, Jul 05, 2014 at 12:20:51PM +0100, Laszlo Papp wrote:
> > To be pedantic, uint32_t was introduced in the Open Group Base
> > Specifications, Issue 5 (released in 1997, basis for UNIX98).
> > At that point it was defined in , which only defined
> > (u)int*_t.
> >
> > As far as when  was available, it was first shipped in glibc
> > 2.1
> > (and prereleases thereof), meaning it was first packaged in Debian 2.1
> > (slink) on sparc.  Slink shipped with kernel 2.0.36.
> > But the names of sized types in the kernel _could_ have been switched
> > over when the standard was released, or rather during any of the "unstable"
> > series after that; this is not a compiler change but a header change,
> > and the kernel has its own headers. Kernel 2.0 was released in 1996
> > (before the standard), but 2.2, 2.4, and 2.6 were released in 1999,
> > 2001, and 2003.
> >
> 
> Glibc is not the only thing, in fact it has not been used much in embedded,
> and even today, it is mostly for "computing embedded".

>From a header standpoint, uClibc effectively is (an old version of)
glibc. From well after the standard types were added. So this is not
an argument against using them.

> > The real reason is mentioned in the kernel coding style manual:
> > some people don't like the "new" types.
> >
> 
> Tes... for good: "do not fix what is not broken".

"Do not fix what is not broken" does not apply here. The kernel
headers have ALWAYS been broken for use in userspace. The UAPI effort
has partly fixed this (and is evidence that they _are_ trying to fix
this, albeit poorly).

Rich
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: [PATCH] Use the standard libc types in fatattr

2014-07-05 Thread Laszlo Papp
On Sat, Jul 5, 2014 at 12:38 AM, Isaac Dunham  wrote:

> On Fri, Jul 04, 2014 at 03:06:04PM +0100, Laszlo Papp wrote:
> > On Fri, Jul 4, 2014 at 2:47 PM, Denys Vlasenko  >
> > wrote:
> >
> > > On Fri, Jul 4, 2014 at 3:26 PM, Laszlo Papp  wrote:
> > > >> > -# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10, __u32)
> > > >> > -# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11, __u32)
> > > >> > +# define FAT_IOCTL_GET_ATTRIBUTES_IOR('r', 0x10,
> uint32_t)
> > > >> > +# define FAT_IOCTL_SET_ATTRIBUTES_IOW('r', 0x11,
> uint32_t)
> > > >> >  #endif
> > > >> >
> > > >> >  /* Currently supports only the FAT flags, not the NTFS ones.
> > > >>
> > > >>
> > > >> Applied, thanks!
> > > >>
> > > >> (why kernel doesn't just use std types?...)
> > > >
> > > > What do you mean by "std types"?
> > >
> > > Like uint32_t
> > >
> >
> > As indicated before, it was only introduced in C99. The kernel project
> > predates that for one.
>
> To be pedantic, uint32_t was introduced in the Open Group Base
> Specifications, Issue 5 (released in 1997, basis for UNIX98).
> At that point it was defined in , which only defined
> (u)int*_t.
>
> As far as when  was available, it was first shipped in glibc
> 2.1
> (and prereleases thereof), meaning it was first packaged in Debian 2.1
> (slink) on sparc.  Slink shipped with kernel 2.0.36.
> But the names of sized types in the kernel _could_ have been switched
> over when the standard was released, or rather during any of the "unstable"
> series after that; this is not a compiler change but a header change,
> and the kernel has its own headers. Kernel 2.0 was released in 1996
> (before the standard), but 2.2, 2.4, and 2.6 were released in 1999,
> 2001, and 2003.
>

Glibc is not the only thing, in fact it has not been used much in embedded,
and even today, it is mostly for "computing embedded".


>
> The real reason is mentioned in the kernel coding style manual:
> some people don't like the "new" types.
>

Tes... for good: "do not fix what is not broken".
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox