RFC: Adding a new (safer) data entry function to libdialog

2003-01-20 Thread Miguel Mendez
Hello hackers,

Currently, when one wants the user to enter data in a libdialog based
program, one uses the following function:

 int
 dialog_inputbox(unsigned char *title, unsigned char *prompt,
int height, int width, unsigned char *result);

The problem this routine has, is that there's nowhere to specify the max
length of the input buffer (think gets vs fgets here). I know that not
many programs use this lib, or even if there are plans to EOL it, but
this change could be helpful IMHO. My suggestion is to create a new
function, e.g, dialog_inputbox_n that would let you specify the length
of the input buffer. Comments? Ideas? If people find it useful I can
come with patches, since the implementation would be trivial.

Cheers,
-- 
Miguel Mendez - [EMAIL PROTECTED]
GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt
EnergyHQ :: http://www.energyhq.tk
Of course it runs NetBSD!



msg39324/pgp0.pgp
Description: PGP signature


Re: nswap

2003-01-20 Thread Mark Santcroos
On Fri, Jan 17, 2003 at 03:27:29PM -0800, David Schultz wrote:
 Thus spake Mark Santcroos [EMAIL PROTECTED]:
  in sys/systm.h:
  extern int nswap;   /* size of swap space */
  
  in vm/vm_swap.c:
  static int nswap;   /* first block after the interleaved devs */
  
  Is the extern pointing to this variable? (It seems so, don't see any other
  such variable in the three)
  If so, is there any problem with making nswap non-static?
 
 It's a constant that is only relevant to the management of the
 swap allocation bitmap, so it is properly static.  It shouldn't be
 declared in sys/systm.h.

I need to get access to the swap interface. More precisely, I want to turn
it off.

Either some of the values and functions need to be made global or the
interface should be changed.

I need this for software suspending on which I am working. (Page in processes 
and turn off swap devices before I write out the memory to it)

Is it worth my time to produce patches that change the swapoff interface?

Mark

-- 
Mark SantcroosRIPE Network Coordination Centre
http://www.ripe.net/home/mark/New Projects Group/TTM

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



Re: verbose device probing ?

2003-01-20 Thread Bruce A. Mah
If memory serves me right, Arun Sharma wrote:

 BTW: There seem to be 30+ critical + 130+ serious bugs against 5.0 at
 the time of its release. Are developers looking at the gnats db at all ?

Yes.

Bruce.

PS.  I personally ignore the severity and priority fields of PRs.  The
importance of many PRs I've dealt with is very much inflated.





msg39326/pgp0.pgp
Description: PGP signature


Re: nswap

2003-01-20 Thread David Schultz
Thus spake Mark Santcroos [EMAIL PROTECTED]:
 On Fri, Jan 17, 2003 at 03:27:29PM -0800, David Schultz wrote:
  Thus spake Mark Santcroos [EMAIL PROTECTED]:
   in sys/systm.h:
   extern int nswap;   /* size of swap space */
   
   in vm/vm_swap.c:
   static int nswap;   /* first block after the interleaved devs */
   
   Is the extern pointing to this variable? (It seems so, don't see any other
   such variable in the three)
   If so, is there any problem with making nswap non-static?
  
  It's a constant that is only relevant to the management of the
  swap allocation bitmap, so it is properly static.  It shouldn't be
  declared in sys/systm.h.
 
 I need to get access to the swap interface. More precisely, I want to turn
 it off.
 
 Either some of the values and functions need to be made global or the
 interface should be changed.
 
 I need this for software suspending on which I am working. (Page in processes 
 and turn off swap devices before I write out the memory to it)
 
 Is it worth my time to produce patches that change the swapoff interface?

What exactly do you need to change about the swapoff interface?
Unless you're trying to write a module, anything that's going to
be invasive into the swap subsystem's data structures probably
belongs in vm_swap.c.

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



Re: RFC: Adding a new (safer) data entry function to libdialog

2003-01-20 Thread Kris Kennaway
On Mon, Jan 20, 2003 at 12:18:51PM +0100, Miguel Mendez wrote:
 Hello hackers,
 
 Currently, when one wants the user to enter data in a libdialog based
 program, one uses the following function:
 
  int
  dialog_inputbox(unsigned char *title, unsigned char *prompt,
   int height, int width, unsigned char *result);
 
 The problem this routine has, is that there's nowhere to specify the max
 length of the input buffer (think gets vs fgets here). I know that not
 many programs use this lib, or even if there are plans to EOL it, but
 this change could be helpful IMHO. My suggestion is to create a new
 function, e.g, dialog_inputbox_n that would let you specify the length
 of the input buffer. Comments? Ideas? If people find it useful I can
 come with patches, since the implementation would be trivial.

libdialog is rife with overflowable buffers..I'm not sure it would be
safe even with this input method.

Kris



msg39328/pgp0.pgp
Description: PGP signature


Re: verbose device probing ?

2003-01-20 Thread Arun Sharma
On Mon, Jan 20, 2003 at 08:33:09AM -0800, Bruce A. Mah wrote:
 
 PS.  I personally ignore the severity and priority fields of PRs.  The
 importance of many PRs I've dealt with is very much inflated.
 

Perhaps you should change the severity field to a lower level then ? Or
is there a different problem (such as lack of good tools) that prevent you
from doing that ?

-Arun

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



device probing not verbose when using boot -v

2003-01-20 Thread Arun Sharma
Submitter-Id:  current-users
Originator:Arun Sharma
Organization:  
Confidential:  no 
Synopsis:  device probing not verbose when using boot -v
Severity:  
Priority:  
Category:  kern
Class: sw-bug 
Release:   FreeBSD 5.0 i386
Environment:

When FreeBSD has trouble booting on some hardware, the lockup is silent
and leaves no clues about where the hang is happening, even if the user
is using boot -v. This makes it very hard for a tester to report
meaningful bugs.

Specific case in question: kern/44619. The hang was in eisa_probe, but
the kernel messages don't provide a clue.

So the proposal is to print the name of the device being probed and
attached before attempting to do it in

kern/subr_bus.c:device_probe_and_attach()

if (bootverbose) is set.

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