Peter Memishian wrote:
> [ This is unrelated to the original topic; changing subject. It'd be nice
> if we could stay on-point. ]
>
> > > > 2) I did find *one* potential issue in ON, which is that struct
> > > > iftun_req has a size of 600. All other ioctls defined in ON header
> > > >
sharath wrote:
> hi. I am working on my academic project in sun on designing the device
> manager for opensolaris based distro. so, i need help in generating the
> devices list. i am using the prtconf -pv command to obtain the device id and
> vendor id. How do i map these to device type.
You mi
Thanks. The problem turned out to be related to the ABI of the platform I'm
porting to. lseek32 has an off32_t parameter. The ABI specifies that ints are
sign extended so the compiler can bypass doing the sign extending when lseek32
calls lseek32_common. I added some "thunking" code to do the pr
hi. I am working on my academic project in sun on designing the device manager
for opensolaris based distro. so, i need help in generating the devices list. i
am using the prtconf -pv command to obtain the device id and vendor id. How do
i map these to device type.
This message posted from o
[ This is unrelated to the original topic; changing subject. It'd be nice
if we could stay on-point. ]
> > > 2) I did find *one* potential issue in ON, which is that struct
> > > iftun_req has a size of 600. All other ioctls defined in ON header
> > > files use sizes that won't be tru
Garrett D'Amore writes:
> Peter Memishian wrote:
> > > files use sizes that won't be truncated.The ioctls impacted are
> > > SIOCGTUNPARAM and SIOCSTUNPARAM.
> >
> > FWLIW, those ioctls are gone in the Clearview gate and will be gone from
> > ON when Clearview IP Tunneling integrates.
> >
James Carlson wrote:
> Garrett D'Amore writes:
>
>>> So, with the putback for 6711665 we have a small
>>> binary incompatibility.
>>>
>>>
>> Ouch. How much of a concern is this (for this particular case)?
>>
>
> Here's a way in which it's a concern: meem rightly notes that the
>
Peter Memishian wrote:
> > 1) The macros themselves that make use of _IOCPARM_MASK (_IOR, _IOW,
> > _IORW) are "private" to ON. That is, external code shouldn't be
> > directly using them. kqemu falls down here. I'm not sure we need to
> > worry about that.
>
> But the macros are older th
Alan Coopersmith wrote:
> Garrett D'Amore wrote:
>
>> 1) The macros themselves that make use of _IOCPARM_MASK (_IOR, _IOW,
>> _IORW) are "private" to ON. That is, external code shouldn't be
>> directly using them.
>>
>
> Are they? I've been working to get our DRI/DRM (graphics direct
>
Garrett D'Amore writes:
> > So, with the putback for 6711665 we have a small
> > binary incompatibility.
> >
> Ouch. How much of a concern is this (for this particular case)?
Here's a way in which it's a concern: meem rightly notes that the
macros are ancient in origin (with the UCB warning la
> 1) The macros themselves that make use of _IOCPARM_MASK (_IOR, _IOW,
> _IORW) are "private" to ON. That is, external code shouldn't be
> directly using them. kqemu falls down here. I'm not sure we need to
> worry about that.
But the macros are older than dirt and common in other Unice
Garrett D'Amore writes:
> 1) Undo the change entirely.
> 2) Define some "compatibility" versions of the macros that are useful
> only to these older ioctls, and make those ioctls use them.
> 3) Ignore the potential for breakage, on some belief (and I don't
> advocate this) that nobody outside of
Garrett D'Amore wrote:
> 1) The macros themselves that make use of _IOCPARM_MASK (_IOR, _IOW,
> _IORW) are "private" to ON. That is, external code shouldn't be
> directly using them.
Are they? I've been working to get our DRI/DRM (graphics direct
rendering, not media rights/restrictions) chan
Darren J Moffat wrote:
> Garrett D'Amore wrote:
>> Jürgen Keil wrote:
>>> Hmm, in the past, nothing prevented me from passing
>>> ioctl parameter structures with a size > 255.
>>>
>>> qemu and it's kqemu kernel module are actually using such a big
>>> structure with the KQEMU_EXEC ioctl.
>>>
>>
Garrett D'Amore wrote
> Jürgen Keil wrote:
> > The putback for 6711665 did break kqemu for me,
> > because the kernel module was compiled on bits before
> > the 6711665 putback, and the qemu application that is
> > using the ioctl was compiled after the putback.
> > The old kernel module didn't un
Garrett D'Amore wrote:
> Jürgen Keil wrote:
>> Hmm, in the past, nothing prevented me from passing
>> ioctl parameter structures with a size > 255.
>>
>> qemu and it's kqemu kernel module are actually using such
>> a big structure with the KQEMU_EXEC ioctl.
>>
>
> Ah, but the encoded size in t
Jürgen Keil wrote:
> Hmm, in the past, nothing prevented me from passing
> ioctl parameter structures with a size > 255.
>
> qemu and it's kqemu kernel module are actually using such
> a big structure with the KQEMU_EXEC ioctl.
>
Ah, but the encoded size in the ioctl will be truncated. If you
I've checked until the point where the dtrace directory is entered (several
screens back), and there is no indication of error. Here are some more lines
immediately preceding the portion that I posted in the first post.
...
..
/usr/bin/rm -f
/cs/systems/home/dsa5/Sol_old_ws/proto/root_i3
Greetings,
just installed OpenSolaris 2008.05 on a new box - very nice, BUT: ld
fails to link (to do anything, actually)!
[EMAIL PROTECTED]:/usr/bin$ ldd ld
libld.so.4 =>/usr/bin/../../lib/libld.so.4
libld.so.4 (SUNWprivate_4.2) => (version not found)
libelf.so.1 =>
James Carlson wrote:
> Jürgen Keil writes:
>
>> James D. Carlson wrote:
>>
>>> Can you explain the incompatibility you found in more
>>> detail? Perhaps in the form of a complete bug report?
>>>
>> The KQEMU_EXEC ioctl was defined like this:
>>
>> % grep KQEMU_EXEC kqemu.h
>> #defin
Jürgen Keil writes:
> James D. Carlson wrote:
> > Can you explain the incompatibility you found in more
> > detail? Perhaps in the form of a complete bug report?
>
> The KQEMU_EXEC ioctl was defined like this:
>
> % grep KQEMU_EXEC kqemu.h
> #define KQEMU_EXEC _IOWR('q', 1, struct kq
> > In particular, how did the kqemu private ioctl change after this
> > integration?
>
> 0xc2487101 => 0xc2487101
Sorry, typo.
Of cause it did change, from 0xc0487101 => 0xc2487101
This message posted from opensolaris.org
___
opensolaris-code mai
James D. Carlson wrote:
> Jürgen Keil writes:
> > The putback for 6711665 did break kqemu for me,
> > because the kernel module was compiled on bits before
> > the 6711665 putback, and the qemu application that is
> > using the ioctl was compiled after the putback.
> > The old kernel module didn't
Jürgen Keil writes:
> The putback for 6711665 did break kqemu for me,
> because the kernel module was compiled on bits before
> the 6711665 putback, and the qemu application that is
> using the ioctl was compiled after the putback. The
> old kernel module didn't understand the new ioctl codes
> an
Daniel Shelepov writes:
> No, the mail message doesn't seem to give any additional insight. Here is the
> relevant output (no errors or warnings until this point):
Look in the nightly.log file, and scan upwards from the first line
with the "not remade because" string in it. You should see a
comp
Hmm, in the past, nothing prevented me from passing
ioctl parameter structures with a size > 255.
qemu and it's kqemu kernel module are actually using such
a big structure with the KQEMU_EXEC ioctl.
The putback for 6711665 did break kqemu for me,
because the kernel module was compiled on bits be
26 matches
Mail list logo
