On Mon, Jan 16, 2006 at 01:56:29PM -0800, Maxim Sobolev wrote: > Hi, Hi Maxim, > IMHO there is better approach to fetch unknown amount of data from the > kernel using ioctl(2) facility. The main idea is that you allocate some > buffer of size sufficient in 95% of cases (for md(4) I think 8-16 > entries are enough), attach it to some structure which has size of the > buffer as one of its members and send pointer to that structure as an > argument to ioctl(2). > > Upon receiving this structure the kernel compares size of the buffer > with amount of information that it needs to send back. If buffer size is > sufficient to hold this information it copies it out and returns number > of entries in the buffer as one of members of this structure. I don't like using array member for holding additional data. We have something similar right now with md_pad[0]. I wanted to prevent us from doing it once again. To do it right, we'd have to add yet another structure describing size of list with pointer to list of disks and the other one for describing separate disks.. but [1] > If the buffer size is insufficient, the kernel fills in desired size of > the buffer in structure members and returns some error code indicating > that the provided buffer is insufficient. Upon receiving this error > userland increases the buffer size to the size suggested by the kernel > (perhaps adding some extra space) and repeats the ioctl(2) calls. > I belive both methods are acceptable since we always end up with sysctl(3)-like problem. Solution you've described will give us one ioctl() call in possitive case, but are there any others advantages? [1] cases in which total device number will change are as probable as using more than 100 md(4) disks ;-) This is why I decided to use simple request for a size and to do a request for md(4) list. -- * Wojciech A. Koszek && dunstan_at_FreeBSD.czest.plReceived on Wed Jan 18 2006 - 07:22:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:51 UTC