On 01/20/2013 19:15, m...@freebsd.org wrote:
This would be fine for a local patch but it breaks existing (valid)
uses that have exactly 8191 bytes of data, so it wouldn't be suitable
for the main FreeBSD repository. Also, in general one wants to have
limits on syscalls that can force a kernel ma
r itself would have to use copyin/copyout to access
> the data. There's no simpler way.
>
>
> I think I found the simpler way, see the draft patch below.
> Generic macro _IOWRE will handle the case when the first integer in ioctl
> parameter holds the actual size of the stru
ink I found the simpler way, see the draft patch below.
Generic macro _IOWRE will handle the case when the first integer in
ioctl parameter holds the actual size of the structure.
This way of passing the variable array sizes is quite common in various
APIs.
Other potential uses would also benefit
On Sun, Jan 20, 2013 at 3:01 PM, Yuri wrote:
> I am implementing an ioctl that reads/writes variable size structure.
> Allocated size is supplied by the caller in the structure itself.
> struct my_struct {
> int len; // allocated size
> other_struct s[1];
> };
> ioctl req
I am implementing an ioctl that reads/writes variable size structure.
Allocated size is supplied by the caller in the structure itself.
struct my_struct {
int len; // allocated size
other_struct s[1];
};
ioctl request id is defined as _IOWR('X', , my_struct)
How to validate from
Hi,
googling brought me to this forum post
http://forums.freebsd.org/showthread.php?p=172885
which reports that xfburn fails to recognize optical drives on FreeBSD 9.0.
There are error messages about a ioctl which might be emitted by libburn
for getting a list of drives:
xfburn: error
On Monday, February 06, 2012 2:44:23 pm PRATIK MOHANTY wrote:
> Hello sir,
> I need some example for ioctl to copy structure from user space to kernel
> space
In BSD the kernel copies the immediate ioctl argument into and out of userland
for you. Thus, you can do something like this
Hello sir,
I need some example for ioctl to copy structure from user space to kernel
space
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-uns
her_status)(int); /* parse address
method */ void(*af_getaddr)(const char *, int); /* parse prefix
method (IPv6) */ void (*af_getprefix)(const char *, int); void
(*af_postproc)(int s, const struct afswtch *); u_long
af_difaddr; /* set dst if add
coming connections with the
>>> 'accept()' system call. Is there a way to specify to accept() that
>>> the newly created file descriptors should be non-blocking (FIONBIO)?
>>> This will avoid an ioctl() after the accept(). Thanks!
>
>> You can make y
l. Is there a way to specify to accept() that
> > the newly created file descriptors should be non-blocking (FIONBIO)?
> > This will avoid an ioctl() after the accept(). Thanks!
> You can make your listening socket non-blocking. Newly created file
> descriptors will inherit t
created file descriptors should be
> non-blocking (FIONBIO)? This will avoid an ioctl() after the accept(). Thanks!
>
> With regards,
> Bernard
Hi Bernard,
You can make your listening socket non-blocking. Newly created file descriptors
will inherit that property. However, th
Hi all,
I want to reduce the number of syscalls for my networking application. The app
handles incoming connections with the 'accept()' system call. Is there a way to
specify to accept() that the newly created file descriptors should be
non-blocking (FIONBIO)? This will avoid an ioc
ng went so good
>> > (read/write), but here I'm going to add support for ioctl.
>> >
>> > int
>> > ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flags, struct
>> thread *td)
>> > {
>> > int error = 0;
>> > upri
went so good
> > > (read/write), but here I'm going to add support for ioctl.
> > >
> > > int
> > > ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flags, struct
> > thread *td)
> > > {
> > > int error = 0;
> > >
On Fri, Dec 24, 2010 at 7:31 PM, Gary Jennejohn
wrote:
> On Fri, 24 Dec 2010 18:17:18 +0330
> Mohammad Hedayati wrote:
>
> > I'm writing a simple char device. So far everything went so good
> > (read/write), but here I'm going to add support for ioctl.
> &g
On Fri, 24 Dec 2010 18:17:18 +0330
Mohammad Hedayati wrote:
> I'm writing a simple char device. So far everything went so good
> (read/write), but here I'm going to add support for ioctl.
>
> int
> ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flags, struct thre
I'm writing a simple char device. So far everything went so good
(read/write), but here I'm going to add support for ioctl.
int
ioctl(struct cdev *dev, u_long cmd, caddr_t data, int flags, struct thread *td)
{
int error = 0;
uprintf("Here...\n");
return(error);
On 31 May 2010 10:19, Kostik Belousov wrote:
> On Sun, May 30, 2010 at 09:50:15PM +0200, Hans Petter Selasky wrote:
>> Hi,
>>
>> The USB team in FreeBSD has discussed this issue internally and would like
>> some advice how to best resolve the 32 bit to 64
On Mon, May 31, 2010 at 12:23:11AM +0200, Hans Petter Selasky wrote:
> On Monday 31 May 2010 00:19:55 Kostik Belousov wrote:
>
> Hi,
>
> > Doesn't this change the existing ABI for 32bit platforms ?
>
> Yes, it changes the ABI.
We do trying hard to keep ABI stable both between and on branches.
>
On Monday 31 May 2010 00:19:55 Kostik Belousov wrote:
Hi,
> Doesn't this change the existing ABI for 32bit platforms ?
Yes, it changes the ABI.
>
> You may take a look at the sys/net/bpf.c, where the similar
> issue is handled for bpf ioctls. To keep the ABI intact, you
> would need to define
On Sun, May 30, 2010 at 09:50:15PM +0200, Hans Petter Selasky wrote:
> Hi,
>
> The USB team in FreeBSD has discussed this issue internally and would like
> some advice how to best resolve the 32 bit to 64 bit IOCTL conversion issue.
>
> Sometimes IOCTL requests contain userlan
Hi,
The USB team in FreeBSD has discussed this issue internally and would like
some advice how to best resolve the 32 bit to 64 bit IOCTL conversion issue.
Sometimes IOCTL requests contain userland pointers of type "void *". When
compiled on a 64-bit OS, sizeof(void *) is 8 byte
On Thu, 29 Apr 2010 23:23:28 +0200 (CEST)
"Lukas Czerner" wrote:
> On Thu, 29 Apr 2010, Ryan Stone wrote:
>
> > Date: Thu, 29 Apr 2010 17:19:41 -0400
> > From: Ryan Stone
> > To: Lukas Czerner
> > Cc: freebsd-hackers@freebsd.org
>
On Thu, 29 Apr 2010, Ryan Stone wrote:
> Date: Thu, 29 Apr 2010 17:19:41 -0400
> From: Ryan Stone
> To: Lukáš Czerner
> Cc: freebsd-hackers@freebsd.org
> Subject: Re: ioctl, copy string from user
>
> > Apparently I need to tell ioctl how big is the variable I am
>
On Thu, 29 Apr 2010, John Baldwin wrote:
> Date: Thu, 29 Apr 2010 16:56:12 -0400
> From: John Baldwin
> To: Lukáš Czerner
> Cc: freebsd-hackers@freebsd.org
> Subject: Re: ioctl, copy string from user
>
> On Thursday 29 April 2010 4:28:31 pm Lukáš Czerner wrote:
> >
> Apparently I need to tell ioctl how big is the variable I am
> providing to it ([MAXLEN]). The odd thing is, when I have a structure
> like this:
>
> struct lrfs_attach_info {
> char *name;
> int priority;
> };
>
> and I pass the pointer to that s
On Thu, 29 Apr 2010, Lukáš Czerner wrote:
> Date: Thu, 29 Apr 2010 22:28:31 +0200 (CEST)
> From: Lukáš Czerner
> To: John Baldwin
> Cc: Lukáš Czerner , freebsd-hackers@freebsd.org
> Subject: Re: ioctl, copy string from user
>
> On Thu, 29 Apr 2010, John Baldwin wrote
here are plenty of examples in the kernel code, but I
> > > > > just can not get it working, so maybe I am doing some stupid mistake
> > > > > I am not aware of. Please give me a hint if you can.
> > > > >
> > > > > What I want
t it working, so maybe I am doing some stupid mistake
> > > > I am not aware of. Please give me a hint if you can.
> > > >
> > > > What I want to do is simply call the ioctl from the userspace with
> > > > (char *) argument. Then, in k
On Thursday 29 April 2010 3:21:00 pm Lukáš Czerner wrote:
> On Thu, 29 Apr 2010, John Baldwin wrote:
>
> > Date: Thu, 29 Apr 2010 14:18:09 -0400
> > From: John Baldwin
> > To: freebsd-hackers@freebsd.org
> > Cc: Lukáš Czerner
> > Subject: Re: ioctl, copy stri
On Thu, 29 Apr 2010, John Baldwin wrote:
> Date: Thu, 29 Apr 2010 14:18:09 -0400
> From: John Baldwin
> To: freebsd-hackers@freebsd.org
> Cc: Lukáš Czerner
> Subject: Re: ioctl, copy string from user
>
> On Thursday 29 April 2010 1:52:45 pm Lukáš Czerner wrote:
> &g
want to do is simply call the ioctl from the userspace with
> (char *) argument. Then, in kernel ioctl handling function copy the
> string argument into the kernel space. I have tried it various ways,
> everything without any success.
>
> *** Userspace ***
> char name[MAXL
On Thu, 29 Apr 2010, Lukáš Czerner wrote:
> Date: Thu, 29 Apr 2010 19:52:45 +0200 (CEST)
> From: Lukáš Czerner
> To: freebsd-hackers@freebsd.org
> Cc: czerner.lu...@gmail.com
> Subject: ioctl, copy string from user
>
> Hi,
>
> I know that there are plenty of example
Hi,
I know that there are plenty of examples in the kernel code, but I
just can not get it working, so maybe I am doing some stupid mistake
I am not aware of. Please give me a hint if you can.
What I want to do is simply call the ioctl from the userspace with
(char *) argument. Then, in kernel
hat this isn't 100% userland code, so the checks should
>>>> be minimalized, but when looking at the ioctl(2) syscall code (at
>>>> least I think it is... there's another dupe hanging around in
>>>> sys/dev/hptmv/ioctl.c), I had some questions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2010/04/22 17:45, Garrett Cooper wrote:
> On Thu, Apr 22, 2010 at 4:36 PM, Matthew Fleming
> wrote:
>>> Hi hackers,
>>> I realize that this isn't 100% userland code, so the checks should
>>> be minima
On Thu, Apr 22, 2010 at 4:36 PM, Matthew Fleming
wrote:
>> Hi hackers,
>> I realize that this isn't 100% userland code, so the checks should
>> be minimalized, but when looking at the ioctl(2) syscall code (at
>> least I think it is... there's another dupe
> Hi hackers,
> I realize that this isn't 100% userland code, so the checks should
> be minimalized, but when looking at the ioctl(2) syscall code (at
> least I think it is... there's another dupe hanging around in
> sys/dev/hptmv/ioctl.c), I had some questions relate
Hi hackers,
I realize that this isn't 100% userland code, so the checks should
be minimalized, but when looking at the ioctl(2) syscall code (at
least I think it is... there's another dupe hanging around in
sys/dev/hptmv/ioctl.c), I had some questions related to the error
handling
On Fri, 26 Mar 2010 01:41:21 +0200, Andriy Gapon wrote:
> On VirtualBox startup the following messages are produced in system log:
> WARNING pid ... (VBoxSVC): ioctl sign-extension ioctl c4a81502
>
> This happens on amd64 platform.
>
> I think the reason for this
On Fri, 26 Mar 2010 11:14:49 +0200, Andriy Gapon wrote:
> on 26/03/2010 10:59 Bernhard Froehlich said the following:
>>
>> I've had a talk to Alexander Eichner and they have already fixed that 2
>> months ago in r25953 on trunk. So VirtualBox 3.2.x will include this
>> fix.
>>
>> http://www.virt
on 26/03/2010 10:59 Bernhard Froehlich said the following:
>
> I've had a talk to Alexander Eichner and they have already fixed that 2
> months ago in r25953 on trunk. So VirtualBox 3.2.x will include this fix.
>
> http://www.virtualbox.org/changeset/25953
Thank you very much.
Sorry for not che
On VirtualBox startup the following messages are produced in system log:
WARNING pid ... (VBoxSVC): ioctl sign-extension ioctl c4a81502
This happens on amd64 platform.
I think the reason for this is in RTFileIoCtl() helper function (in
VBox/Runtime/r3/posix/fileio-posix.cpp).
This
> Danny Braniss wrote:
> >> Danny Braniss wrote:
> actually it's the struct thread *tp where my problems are,
> this code works fine under 6.2, and did work till some days ago under
> current.
>
> static int
> iscsi_open(struct cdev *dev, int flags, int otype, struct
Danny Braniss wrote:
Danny Braniss wrote:
actually it's the struct thread *tp where my problems are,
this code works fine under 6.2, and did work till some days ago under current.
static int
iscsi_open(struct cdev *dev, int flags, int otype, struct thread *td)
{
...
debug(3, "td->td_pro
> Danny Braniss wrote:
> >> actually it's the struct thread *tp where my problems are,
> >> this code works fine under 6.2, and did work till some days ago under
> >> current.
> >>
> >> static int
> >> iscsi_open(struct cdev *dev, int flags, int otype, struct thread *td)
> >> {
> >> ...
> >>de
Danny Braniss wrote:
actually it's the struct thread *tp where my problems are,
this code works fine under 6.2, and did work till some days ago under current.
static int
iscsi_open(struct cdev *dev, int flags, int otype, struct thread *td)
{
...
debug(3, "td->td_proc=%p", td->td_proc);
actually it's the struct thread *tp where my problems are,
this code works fine under 6.2, and did work till some days ago under current.
static int
iscsi_open(struct cdev *dev, int flags, int otype, struct thread *td)
{
...
debug(3, "td->td_proc=%p", td->td_proc);
debug(3, "td->td
> actually it's the struct thread *tp where my problems are,
> this code works fine under 6.2, and did work till some days ago under current.
>
> static int
> iscsi_open(struct cdev *dev, int flags, int otype, struct thread *td)
> {
> ...
> debug(3, "td->td_proc=%p", td->td_proc);
> de
r(1, "error opening /dev/ata");
}
bzero(&iocmd, sizeof(struct ata_cmd));
iocmd.channel = channel;
iocmd.device = channel;
iocmd.cmd = ATAGPARM;
if (ioctl(fd, IOCATA, &iocmd) == -1) {
err(1,
Mohsen Pahlevanzadeh <[EMAIL PROTECTED]> writes:
> Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes:
> > [The] code should build cleanly on a stock install of FreeBSD 6.0 or
> > newer.
> Our FreeBSD is 4.11 because we can't use another version.
In that case, we can't help you.
DES
--
Dag-Erling Sm
Viktor Vasilev <[EMAIL PROTECTED]> writes:
> On Sunday 13 May 2007 18:17 Mohsen Pahlevanzadeh wrote:
> > When i compile it,gcc tell me that IOCATAGPARM isn't declare.
> > May i patch for kernel?
> Maybe you just didn't install the src distribution.
He doesn't need to. Your code should build clean
> Please help me
> >
> > For an ATA disk you can use the IOCATAGPARM ioctl to get the
> > information. See the attached C source for example. Be sure to have a
> > look
> > at /usr/src/sys/sys/ata.h for other relevant fields and sizes.
> >
> Dear all,
ial number of hdd.
> Please help me
For an ATA disk you can use the IOCATAGPARM ioctl to get the information.
See the attached C source for example. Be sure to have a look
at /usr/src/sys/sys/ata.h for other relevant fields and sizes.
Cheers,
Vik
___
On Sun, 13 May 2007, Mohsen Pahlevanzadeh wrote:
Dear all,
I need to a code piece that it gets serial number of hdd.
Please help me..
___
see source for 'atacontrol info' for ATA type disks.
see source for 'camcontrol inquiry' for SCSI type di
On Sun, May 13, 2007 at 05:29:48PM +0330, Mohsen Pahlevanzadeh wrote:
> Dear all,
> I need to a code piece that it gets serial number of hdd.
> Please help me
"atacontrol cap" shows you the serial number.
--
B.Walterhttp://www.bwct.de http://www.fizon.de
[EMAIL PROTECTED
On Sunday 13 May 2007 16:57 Viktor Vasilev wrote:
> On Sunday 13 May 2007 15:59 Mohsen Pahlevanzadeh wrote:
> > Dear all,
> > I need to a code piece that it gets serial number of hdd.
> > Please help me
>
> For an ATA disk you can use the IOCATAGPARM ioctl to get
On Sunday 13 May 2007 15:59 Mohsen Pahlevanzadeh wrote:
> Dear all,
> I need to a code piece that it gets serial number of hdd.
> Please help me
For an ATA disk you can use the IOCATAGPARM ioctl to get the information.
See the attached C source for example. Be sure to have a look
Dear all,
I need to a code piece that it gets serial number of hdd.
Please help me..
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Dear all,
I need to a code piece that it gets serial number of hdd.
Please help me
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On 28.09-13:40, rashmi ns wrote:
[ ... ]
> I was trying to add a new ioctl command like
> > #define HDLCMODE _IOR('6',0xF,int)
> > when i trying to uprintf the data which was sent from the user-space in
> > the device-driver-ioctl-routine i'll get a different
rashmi ns wrote:
#define HDLCMODE _IOR('6',0xF,int)
when i trying to uprintf the data which was sent from the user-space in
the device-driver-ioctl-routine i'll get a different value than which was
passed. Can anybody please tell me why this is happening . I pass the
address of a
> Hello All ,
Sorry for resending the message many times !!!.
I was trying to add a new ioctl command like
> #define HDLCMODE _IOR('6',0xF,int)
> when i trying to uprintf the data which was sent from the user-space in
> the device-driver-ioctl-routine i'll get a dif
-March/005014.html
Hello,
I just installed a Soundblaster 16 (DSP v4.16) in my FreeBSD
machine, and found no way to enable the 3D stereo enhancement
feature that the Linux, DOS and Win9x drivers support. So I
looked at the Linux driver sources and decided to add a
compatible mixer ioctl
On Thu, Feb 24, 2005 at 01:03:17AM +0800, Xin LI wrote:
> On Mon, Feb 21, 2005 at 10:16:56PM +, Wojciech A. Koszek wrote:
> > Hello hackers,
> > I would like to let you know I've been doing [partial] audit of ioctl()
[..]
> > connections.
> Default devfs confi
On Mon, Feb 21, 2005 at 10:16:56PM +, Wojciech A. Koszek wrote:
> Hello hackers,
> I would like to let you know I've been doing [partial] audit of ioctl()
> code. There are some places, which may interest you. These are:
>
> sys/cam/cam_xpt.c
> sys/contrib/ipfilter
On Mon, Feb 21, 2005 at 10:16:56PM +, Wojciech A. Koszek wrote:
> Hello hackers,
> I would like to let you know I've been doing [partial] audit of ioctl()
> code. There are some places, which may interest you. These are:
>
> sys/cam/cam_xpt.c
> sys/contrib/ipfilter
Hello hackers,
I would like to let you know I've been doing [partial] audit of ioctl()
code. There are some places, which may interest you. These are:
sys/cam/cam_xpt.c
sys/contrib/ipfilter/netinet/ip_fil.c
sys/contrib/pf/net/pf_ioctl.c
sys/dev/ata/ata-all.c
sys/dev/md/md.c
sys/geom/geom_
In the last episode (Oct 14), Shawn Webb said:
> I've got to rewrite the source due to hard disk problems, so I'll just put
> it in this email:
>
> arg = FORMAT;
> if (ioctl(fd, SNDCTL_DSP_SETFMT, &arg) < 0)
> {
> perror("ioctl setfm
quot;);
exit(0);
}
void this_segfaults(void)
{
int arg;
arg = FORMAT;
if (ioctl(fd, SNDCTL_DSP_SETFMT, &arg) < 0)
{
perror("ioctl setfmt");
exit(1);
}
if (ioctl(fd, SNDCTL_DSP_GETOSPACE, &arg) < 0)
{
perror("ioctl getospa
On Tue, 12 Oct 2004, Shawn Webb wrote:
> (attached is the source code to the segfaulting application)
Doesn't appear to be -- if it was a large attachment, maybe the mailing
list stripped it. Could you give a URL for the source?
Robert N M Watson FreeBSD Core Team, TrustedBSD Proj
I have stumbled upon a local DoS (non-kernel) while writing a VoIP app for
FreeBSD. The DoS exists when two ioctl calls (or less/more?) are followed by
a malloc call to malloc a pointer in global scope which is then followed by
two more (or less/more?) ioctl calls. The result is a stack smash
Artis Caune wrote:
> Is it correct to use code like this
> instead of copyin() / copyout() ?
> Kernel module gets pointer to structure
> which resides in userland memory space
> and modify it directly!!!
The copyout() is just hidden.
The ioctl request codes are magic and cont
On Thursday 06 May 2004 03:57 am, Artis Caune wrote:
> Is it correct to use code like this
> instead of copyin() / copyout() ?
> Kernel module gets pointer to structure
> which resides in userland memory space
> and modify it directly!!!
No, that's probably bogus.
>
Is it correct to use code like this
instead of copyin() / copyout() ?
Kernel module gets pointer to structure
which resides in userland memory space
and modify it directly!!!
> userland: ioctl(tp_fd, TP_GET_TP_STATS, &tp_stats)
> kernel: tp_stats->hooked = hooked;
(fre
Woops,
Please disregard the previous post ... amature programmer at play. Can
an ioctl call return before processing the request? When I started using
seperate variables for the int=1 and int=0 ioctl values, everything works
fine.
-Matthew
>Question,
>
> Is there somthing ma
ed to open a packet filter device\n" );
printf( "exiting ...\n" );
return -1;
}
printf( "using filter device '%s'\n", device );
// assign the filter to a network device
struct ifreq ifr;
strcpy(
On Mon, 11 Mar 2002, Rajesh P Jain wrote:
> In the BPF - Berkeley Packet Filter, when a file descriptor is
> associated to an interface to send and receive packets, there is an
> ioctl parameter "BIOCSSEESENT", which is by default set to 1. Hence the
> packets both fro
Hi,
In the BPF - Berkeley Packet Filter, when a file descriptor is associated to an
interface to send and receive packets, there is an ioctl parameter "BIOCSSEESENT",
which is by default set to 1. Hence the packets both from "remote systems" and
"locally generat
when the driver ioctl (i.e. ifp->if_ioctl) is called with either
SIOCADDMULTI or SIOCDELMULT, NULL value is passed as data argument to the
ioctl function. but going through the code(in net/if.c file if_addmulti
and if_delmulti functions) doesn't reveal the logic behind it. can anyone
tel
Originally posted to -net but no replies,
maybe some here could help me out? tia, Andy
-Original Message-
To: [EMAIL PROTECTED]
Subject: ioctl and fxp/tl drivers
Hi all
This maybe a dumb question but a bit
stumped at the mo. When I make an
ioctl call to the fxp or tl drivers
thus
> In message <[EMAIL PROTECTED]> Gregory Bond writes:
> : The existing driver occasionally does "return(-ENODEV);" from (functions ca
> lled
>
> Linux does that.
>
> : from) the device ioctl routine. The new driver that I am trying to fold in
> : does &
In message <[EMAIL PROTECTED]> Gregory Bond writes:
: The existing driver occasionally does "return(-ENODEV);" from (functions called
Linux does that.
: from) the device ioctl routine. The new driver that I am trying to fold in
: does "return ENODEV;".
That's c
[pls cc me I'm not normally on -hackers]
I'm working on updating the istallion mulitport serial driver into -Stable.
The existing driver occasionally does "return(-ENODEV);" from (functions called
from) the device ioctl routine. The new driver that I am trying to fold in
Hi,
> Yeah, that's basically what I had to do in tdfx. You can take
> a look int src/sys/dev/tdfx/tdfx_pci.c under tdfx_ioctl(...)
Great. Thanks for the pointer.
I've just tested ioctl return values in some test code
and it works ok.
Thanks
Roger
To Unsubscribe: send mail to
Yeah, figured that one out too. bleh.
Dennis had the audacity to say:
>
> oh, also, they MUST be negative. so you return (-ENODEV)...some bad upper
> layer code they decided to never fix.
>
> DB
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the
int
> > > src/sys/dev/tdfx/tdfx_pci.c under tdfx_ioctl(...) to get an idea of what
> > > needs to be done, if you need more info. Tdfx basically implements the
> > > API from device_3dfx in Linux.
> >
> > Is there anyone we can PLEAD with to explain that to the lin
s/dev/tdfx/tdfx_pci.c under tdfx_ioctl(...) to get an idea of what
> > > needs to be done, if you need more info. Tdfx basically implements the
> > > API from device_3dfx in Linux.
> >
> > Is there anyone we can PLEAD with to explain that to the linnux people
> &
s/dev/tdfx/tdfx_pci.c under tdfx_ioctl(...) to get an idea of what
> > > needs to be done, if you need more info. Tdfx basically implements the
> > > API from device_3dfx in Linux.
> >
> > Is there anyone we can PLEAD with to explain that to the linnux people
> &g
t; > needs to be done, if you need more info. Tdfx basically implements the
> > API from device_3dfx in Linux.
>
> Is there anyone we can PLEAD with to explain that to the linnux people
> that that's a broken way to implement ioctl()?
I did the original port of the linux
ments the
> API from device_3dfx in Linux.
Is there anyone we can PLEAD with to explain that to the linnux people
that that's a broken way to implement ioctl()?
> Alfred Perlstein had the audacity to say:
> >
> > * Roger Hardiman <[EMAIL PROTECTED]> [010326 05:37] wrote:
>
o say:
>
> * Roger Hardiman <[EMAIL PROTECTED]> [010326 05:37] wrote:
> > Hi,
> > I'm porting the some linux telephony API drivers over
> > to FreeBSD.
> >
> > But the author of the linux driver used the 'hack' of
> > returning values fr
* Roger Hardiman <[EMAIL PROTECTED]> [010326 05:37] wrote:
> Hi,
> I'm porting the some linux telephony API drivers over
> to FreeBSD.
>
> But the author of the linux driver used the 'hack' of
> returning values from the ioctls as the error result.
>
Hi,
I'm porting the some linux telephony API drivers over
to FreeBSD.
But the author of the linux driver used the 'hack' of
returning values from the ioctls as the error result.
eg volume = ioctl (fd, IXJ_GET_VOLUME)
instead of using
error = ioctl (fd, IXJ_GET_
Soren Schmidt <[EMAIL PROTECTED]>, said on Mon Feb 26, 2001 [09:10:43 PM]:
} It seems Stephen Rose wrote:
} > A couple of us on the questions list have asked for a way to spin down ide
} > disks when idle. Is there any chance that this utility could lead to
} > something useful there?
}
} Well,
have to keep it spun down for long periods to make it worth
> the effort, and you wear significantly more on the mechanics this
> way too...
>
> > It seems Scott Renfro wrote:
> > > As I promised on -mobile earlier this week, I've cleaned up my patches
> > > t
x27;ve cleaned up my patches
> > to port the {Net,Open}BSD atactl utility, including a simplistic
> > ata-disk ioctl. They apply cleanly against this afternoon's -stable
> > (including Soren's latest commit bringing -stable up to date with
> > -current). I
gt; to port the {Net,Open}BSD atactl utility, including a simplistic
> ata-disk ioctl. They apply cleanly against this afternoon's -stable
> (including Soren's latest commit bringing -stable up to date with
> -current). I've been running them for some time and they '&#x
On Mon, Feb 26, 2001 at 08:28:56AM +0100, Soren Schmidt wrote:
>
> No its not safe at all, you risk trashing an already running command...
Thanks for the feedback; that's exactly what I was concerned about.
> Anyhow, I have an atacontrol thingy in the works for attach/detach,
> raid control etc
1 - 100 of 190 matches
Mail list logo
