On Nov 2, 2009, at 12:34 PM, Kostik Belousov wrote:
On Mon, Nov 02, 2009 at 10:08:17AM -0800, Marcel Moolenaar wrote:
For a change that does change the ABI: revision 198506
tcsh(1) dumps core with a sig 11...
Can you provide some details ? Which architecture is it ?
What is the backtrace ? W
On Mon, Nov 02, 2009 at 10:08:17AM -0800, Marcel Moolenaar wrote:
> For a change that does change the ABI: revision 198506
> tcsh(1) dumps core with a sig 11...
Can you provide some details ? Which architecture is it ?
What is the backtrace ? What is the ktrace before SIGSEGV ?
pgpCijm98aQWH.pg
On Nov 2, 2009, at 7:54 AM, Ed Schouten wrote:
* M. Warner Losh wrote:
And you haven't answered my question: Have you confirmed that there's
no ABI changes on all platforms?
Confirmed on all platforms? No. I've only tested it on i386 and
amd64. I
think someone also tested it on arm, so t
* M. Warner Losh wrote:
> And you haven't answered my question: Have you confirmed that there's
> no ABI changes on all platforms?
Confirmed on all platforms? No. I've only tested it on i386 and amd64. I
think someone also tested it on arm, so this makes me believe other
architectures will also w
In message: <20091102102404.gp1...@hoeg.nl>
Ed Schouten writes:
: Hello David,
:
: * David Malone wrote:
: > Surely it is an API change, but not an ABI change? Code that used
: > to do:
: >
: > d.d_uid = 3;
: >
: > will no longer compile, but code that was comipled with the old
Hello David,
* David Malone wrote:
> Surely it is an API change, but not an ABI change? Code that used
> to do:
>
> d.d_uid = 3;
>
> will no longer compile, but code that was comipled with the old
> version will still run. I understand that the assignment doesn't
> do anything useful, but
On Sun, Nov 01, 2009 at 02:12:12AM +0100, Ed Schouten wrote:
> No, we don't. All these fields are not used by drivers, just some old
> version of the devfs code. I made sure struct cdevsw didn't change in
> size, so there should be no API nor ABI conflicts.
Surely it is an API change, but not an A
On 1 Nov 2009, at 15:33, Ed Schouten wrote:
Because d_kind is a pointer, there will be a hole in the structure
of at
least 2 bytes (maybe even 6), which means we can safely extend
d_mode to
32 bits as well. I could have decided to leave it at uint16_t, but
that
would only obfuscate it eve
Hi Robert,
* Robert Watson wrote:
> The underlying change seems fine, especially in -CURRENT, but I'm
> confused by the paragraph here on alignment and safety. What do you
> mean by safe, and does it matter?
With safe I mean that all useful members still begin at the same offset
within the stru
On Sat, 31 Oct 2009, Ed Schouten wrote:
Turn unused structure fields of cdevsw into spares.
d_uid, d_gid and d_mode are unused, because permissions are stored in
cdevpriv nowadays. d_kind doesn't seem to be used at all. We no longer
keep a list of cdevsw's, so d_list is also unused.
uid_
In message: <20091101011212.gg1...@hoeg.nl>
Ed Schouten writes:
: Hi Warner,
:
: * M. Warner Losh wrote:
: > Don't we need a D_VERSION bump for this?
:
: No, we don't. All these fields are not used by drivers, just some old
: version of the devfs code. I made sure struct cdevsw didn
Hi Warner,
* M. Warner Losh wrote:
> Don't we need a D_VERSION bump for this?
No, we don't. All these fields are not used by drivers, just some old
version of the devfs code. I made sure struct cdevsw didn't change in
size, so there should be no API nor ABI conflicts.
--
Ed Schouten
WWW: ht
In message: <200910311035.n9vazfib082...@svn.freebsd.org>
Ed Schouten writes:
: Author: ed
: Date: Sat Oct 31 10:35:41 2009
: New Revision: 198706
: URL: http://svn.freebsd.org/changeset/base/198706
:
: Log:
: Turn unused structure fields of cdevsw into spares.
:
: d_uid, d_gid
Author: ed
Date: Sat Oct 31 10:35:41 2009
New Revision: 198706
URL: http://svn.freebsd.org/changeset/base/198706
Log:
Turn unused structure fields of cdevsw into spares.
d_uid, d_gid and d_mode are unused, because permissions are stored in
cdevpriv nowadays. d_kind doesn't seem to be used
14 matches
Mail list logo
