This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more infromation.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: FYI: gdb-4.18 + target ARM (or Thumb) used with Angel + Debian GNU/Linux


Christian Ericsson <christian.ericsson@bigfoot.com> wrote:
> The problem was that normal Linux systems use /dev/cua0
> as the first serial port, but Debian GNU/Linux 2.1 (which I use)
> use /dev/ttyS0 instead. I did try to make a soft link, like:
> ln -s /dev/ttyS0 /dev/cua0
> But, it didn't solve the problem. The serial port to use is
> hard coded! So, I changed the right source code file to use
> /dev/ttyS0 instead of /dev/cua0. And, now it works!
> 
> If you are using Red Hat Linux, you will not need any patching!
> 
> I'm going to make a bug report to the gdb-team.

Your fix is actually the correct thing to do, and the gdb maintainers should
make /dev/ttyS0 the default on Linux (but not on some other operating systems,
such as SunOS 4).  /dev/cua* are obsolete and deprecated, which is presumably
why Debian doesn't include them.  /dev/ttyS* follow the standard POSIX
sematics, and should work fine.

Below is a meesage from Theodore Y. Ts'o explaining this in more detail.
(Taken from the mgetty+sendfax FAQ).

Eric
-----------------------------------------------------------------------------
From: "Theodore Y. Ts'o" <tytso@mit.edu>

  /dev/ttySxx devices are fully POSIX-compliant TTY devices.  If you are
  only going to be using one set of tty devices, you should be using
  /dev/ttySxx.

  /dev/cuaXX devices are different from /dev/ttySXX in two ways ---
  first of all, they will allow you to open the device even if CLOCAL is
  not set and the O_NONBLOCK flag was not given to the open device.
  This allows programs that don't use the POSIX-mondated interface for
  opening /dev/ttySxx devices to be able to use /dev/cuaXX to make
  outgoing phone calls on their modem (cu stands for "callout", and is
  taken from SunOS).

  The second way in which /dev/cuaXX differs from /dev/ttySXX is that if
  they are used, they will trigger a simplistic kernel-based locking
  scheme:  If /dev/ttySXX is opened by one or more processes, then an
  attempt to open /dev/cuaXX will return EAGAIN.  If /dev/cuaXX is
  opened by one or more processes, then an attempt to open /dev/ttySXX
  will result the open blocking until /dev/cuaXX is closed, and the
  carrier detect line goes high.

  While this will allow for simple lockouts between a user using a modem
  for callout and a getty listening on the line for logins, it doesn't
  work if you need to arbitrate between multiple programs wanting to do
  dialout --- for example, users wanting to do dialout and UUCP.

  I originally implemented the cuaXX/ttySXX lockout mechanism back
  before FSSTND established a standard convention for the use of tty
  lock files.  Now that it's there, people should use the tty lock files
  and not try using /dev/cuaXX.  The only reason why /dev/cuaXX hasn't
  disappeared yet is for backwards compatibility reasons.  - Ted

  Under SunOS *everything* should use cua*, as follows: From: Gert
  Doering <gert@muc.de>

  The two-device scheme is meant to prevent multiple processes from
  accessing the same physical device at the same time. Since mgetty
  opens the port with O_NDELAY, the kernel sees a process on tty*
  (mgetty) and prevents any open() on cua* (uucico, cu, ...). So, you
  have to use the same device for both program types, and that's cua*.
_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]